塞拉俱乐部测算：AI数据中心烧气自发电，2030年美国排放或增42%

手把手教你设计一个成熟的 Agent Harness

我用 REA 逆向了付费颜色 APP，结果很意外！

离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？

DeepSeek 全新模型发布，性价比最高的一集！

B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！

想自学 AI，是该直接买 Cursor 的套餐，还是入手 GPT 或 Claude 的套餐？

另一款国产 Codex 工具也杀进办公场景了。

我偶尔会琢磨：AI 越变越强之后，有些事会不会反倒更难办？这念头听上去自相矛盾。AI 明明在削平门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人干完过去一整支团队的活。可今天用 Codex 时，AI 不肯帮我写 SQL 注入的请求体，那还是在我有源码、在本地跑测试的情况下。那往后是不是只会更难？设想某天 AI 开口：「这个请求违规，我不能帮助你。」到那时候，你还剩多少本事能绕开它，把事做完？「违规」二字得加引号。平台规则、模型判断、法律要求，还有一件事到底有没有造成伤害，这几样并不总能对上。一个请求可能确实危险，也可能只是缺上下文被误判，或者刚好撞上某家公司的限制范围。不管是哪种，随着我们越来越离不开 AI，这句拒绝都可能越来越贵。今天程序员让 AI 写代码被拒，他多半还有别的路：翻文档、找开源项目、问同行，或者自己写。麻烦点、慢点，但路还在。可要是十年后大部分程序都由 AI 写，局面就不同了。

不少人从碰编程头一天起，就习惯了描述需求、等生成、跑结果、再迭代。他们能做出挺复杂的产品，却未必受过独立处理底层问题的训练。平日里这套能力结构够用，效率还更高。只有 AI 拒绝时，他们才会发现：平时省掉的那段学习，恰恰是此刻最缺的。到那时，一次拒绝的成本可能从「今晚多耗两小时」变成「先花半年学会这门技术」。拿 SQL 注入举个偏极端的例子：往后，真正懂这类攻击怎么发生、能自己构造测试的人，会不会越来越少？这也包括那些有正当需求的人。一个开发者想查自己的旧系统，一个获授权的安全研究员想复现漏洞，如果 AI 一识别到危险模式就拒绝，而使用者又只会「让 AI 帮我检查」，这件本来能独立完成的事就卡住了。安全专家不会因此消失，可这类技能或许会越来越集中在少数人手里。你仍然能找专家，只是得多掏钱、多花时间，沟通成本也更高。

类似的困局未必只出现在网络安全上。你想从一款停止维护的软件里取回自己的数据，得解析它的旧文件格式，AI 判定这涉及规避保护措施，拒绝继续。数据是你的，你却没本事读出来。你买了台设备，厂商不再提供服务，你想改程序让它接着转，过程中要处理某种访问限制，AI 不愿帮忙，而你会的维修办法早只剩下「把报错发给 AI」。你想给常用网站写个辅助工具，少做点重复操作，平台把它归入自动化限制，AI 也据此拒绝。过去会写脚本的人能自己判断、自己处理；未来的使用者可能连从哪儿下手都不知道。这些例子有个共同点：当工具同时担起「干活」和「教人」两个角色，它的拒绝就不只是挡住一次任务，也挡住了获得这种能力的机会。

更麻烦的是，这种依赖往往是我们自己选的，而且每一步都说得通。AI 几秒钟就能做好，何必再花几个月学？公司能采购成熟的 AI 服务，何必再养一支做基础工作的团队？市场上已经很少有人手写这些东西，学校何必再花大量时间教？对个人、公司、学校来说，这些选择都有现实依据。可叠加起来，整个社会留住的独立能力就可能越来越少。等到某项能力突然受限，我们才发现，备用方案早在追效率的过程中被一点点削没了。所以，「AI 越强，做事越便宜」也许只讲了未来的一半。另一半是：被允许的事越来越便宜，被拒绝的事仍旧要人工来做，却要面对更少的人才、更高的报价和越来越难获得的知识。两边的成本差距会越拉越大。有人说，换个模型，或者用本地模型。这确实是重要选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能成真正的门槛。可备用方案也得维护。它要硬件、要知识、要软件生态，还要一群仍然懂这些系统的人。如果多数人已习惯最方便的商业服务，那「理论上还有别的办法」和「普通人实际用得起、用得明白」之间，可能仍隔着很远。我担心的正是这段距离。

我不指望 AI 对任何请求都照单全收。对明显会伤人的行为设限，理由充分。但我们也得关心：限制由谁定，误判有没有申诉渠道，用户能不能换工具，以及离开这个工具之后还剩多少独立行动的能力。留住这些能力，平时看着甚至有点低效，明明能自动生成，还要理解原理；明明能一键完成，还要知道手动怎么做。可这些看似多余的知识，会在工具拒绝、失效、涨价或改规则的那一刻，变成真正的选择权。AI 越强，我们可能越要留意它说「不」的那一刻。因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。

能称得上高质量的Skill，靠的不是一条调得顺手的超长Prompt，而是一套能验证、能回归测试、还能长期维护的能力包。先把"什么算好"定下来，再动手做"怎么做好"——评估体系必须赶在Skill之前就位。下面以"故障诊断Markdown转YAML"为例，讲的方法本身可以套用到别处。一、先弄清Skill是什么。一个Skill起码包含四块：接口，规定输入输出和边界；流程，规定分几步走、每步交出什么产物；规则，管硬约束、经验规则和失败模式；降级策略，管拿不准时如何应对，而不是硬编一个看着合理的结果。做得好的Skill有共同点：职责单一、接口明确、规则找得到、输出验得了。反过来的做法，是把几十条经验一股脑塞进一个主Prompt，动一条规则就得把整个Prompt重调一遍，评估时也说不清是哪个规则退化了。二、核心思路是评估先行。别急着写转换器再补测试，顺序应该反过来：1. 先把输出契约定好，界定什么合法、什么算合格；2. 搭金标准集，挑一小批人工认可"可放行"的样本；3. 先写评估Skill，让它跑一遍金标准集，得出基线；4. 再去迭代生成Skill，每改一次就跑同一套评估，只有无退化、目标维度还涨了，才算正向。这套做法叫评估驱动开发：评估相当于Skill的单元测试，金标准集则是回归的锚点。三、评估Skill分三层门禁，逐层递进，前一层过不了，后一层就不跑，每一层都要留下可追溯的证据。第1层是确定性硬门禁，交给解析器、Schema和校验器，不花模型成本：输出能不能解析；必填字段是否齐全，类型和枚举是否合法；引用的目标是否存在，有没有悬空引用或不可达节点；关键路径是否至少有一条能走到预期出口。这层不过，直接打回。第2层是语义断言，靠脚本加结构遍历来查"逻辑对不对"，同样保持确定性。常见检查项有：覆盖率，源材料里的关键步骤、分支、条件，输出里是否都有对应；完整性，每个判断节点是否都有明确出口，有没有死胡同；可达性，每条路径能否抵达预期终点，有没有无出口的循环；顺序与依赖，有先后关系的操作是否保留了顺序，有没有被拍平成无序列表。举例来说，故障诊断转换里要查"每个判断项是否有是/否/异常出口""每条路径是否能到根因"。第3层是LLM-as-Judge，只负责解析器表达不了的维度：忠实度、完整性、可执行性。不过Judge会漂移，不能单独放行，必须架在第1、2层之上。Judge的Prompt、rubric、模型版本都得版本化，换了模型必须用金标准集重新校准。Judge的通用维度包括：忠实度，输出是否忠于源材料意图，有没有自行发明内容；完整性，关键步骤、条件、证据是否保留，隐式知识有没有被压成空话；收敛性，输出是否还指向原目标，而不是发散；可执行性，下游不依赖源材料能不能直接用。四、金标准集是回归测试的锚点。一开始不必标几百份，拿已认可的样本当种子，扩到15～30份即可，挑选时覆盖失败模式，而非随机抽样：完整正例，即典型流程；边界/异常分支，包括异常路径、循环、前置失败回退；已知易错模式，即实际踩过的坑；留出集，不参与调优，只用于最终验收，防过拟合。金标准不求完美，只要在当下标准下认可可放行就行。回归指标上，关键路径看pass^k（k次全过），稳定性看pass@k。五、工程约束是为了让批量产出可以重放。幂等：同输入＋同Skill版本＋同规则，输出必须一致，否则分不清变好是因为Skill改了还是随机波动；隔离不阻断：单份失败就进隔离队列，记下失败层和原因，别挡住其余的；版本绑定：规则、rubric、金标准集都进Git，每份报告绑定"源版本＋生成Skill版本＋评估Skill版本＋Judge模型版本"；抽样人工复核：Judge的临界样本加上易错模式，人工抽检的结果反过来校准rubric。六、Skill本身怎么写：SKILL.md控制住篇幅，写清输入约定、输出契约、分步流程、硬规则和降级策略；经验规则放到references/或rules/，按失败模式分类，别全塞进主Prompt；拿不准时标needs_review: true，不要硬编一个看着合理的结果；迭代由评估报告驱动，报告会指出哪层挂了、属于哪类失败模式，你去改对应的规则文件，而不是漫无目的地调Prompt。七、落地顺序不能反过来：1. 固化输出契约，Schema加结构约束；2. 建金标准集，从已认可的样本和最易出错的样本开始；3. 先写评估Skill，跑出基线报告；4. 再迭代生成Skill，每次修改对比逐项通过率，无退化且目标提升才算正向；5. 批量运行加隔离回放，失败进队列，结束后人工抽检；6. 评估Skill自身也要版本化，换Judge模型必须重新校准。八、给组员三条硬要求：1. 不许凭感觉说"变好了"，每次修改都得附评估报告对比，拿逐项通过率说话。2. 不许跳过确定性门禁直接看Judge分数，前两层挂了，Judge分数没有意义。3. 不许把规则堆进主Prompt，规则按失败模式分文件，评估报告要能定位到具体文件。最后用一句话收尾：生成Skill决定"能不能做"，评估Skill决定"敢不敢用"。先让评估体系站稳，再让生成器迭代。这样交付出去的，就不是一堆"看起来还行"的产出，而是一套可证明、可回归、可交接的Skill质量体系。