参谋而非指挥官：一套更可靠的 AI 应用与 AI Coding 工作流

如果要把一句话作为这篇文章的中心，那就是：

AI 更适合做参谋，而不是指挥官。

这不是因为 AI 没用，恰恰相反，是因为它非常有用，所以更需要把它放在正确的位置。

很多人对 AI 的误解都来自两个极端：

• 要么无脑接受，只要 AI 给出东西就继续往下推进
• 要么一旦看不懂它在干什么，就立刻打断，终止整个过程

这两种做法都会导致大量糟糕的决策。

一、为什么 AI 不能当“指挥官”

AI 会时不时犯错，而且犯错的方式并不稳定。常见来源大概有三类：

1. 信息偏差
2. 目标对齐不充分
3. 算法或推理错误

这意味着，只把 AI 当成“给答案的人”是不够的。你必须持续观察它在做什么、为什么这么做、偏差是怎么产生的。

所以对复杂任务更合理的定位不是：

• “AI 替我做决定”

而是：

• “AI 先提出方向、展开工作、给出候选方案”
• “人负责关键判断、边界把控、纠偏和最终决策”

这也是为什么我更喜欢把 AI 看成：

• 参谋
• 讨论对象
• 执行协作者

而不是全自动指挥官。

二、真正决定结果上限的是人的判断力

AI 的输出质量，最后一定会受限于人的能力。

原因很简单：

• 你对工作的标准，决定了你能不能识别坏结果
• 你对过程是否清楚，决定了你能不能发现偏差
• 你对关键设计有没有想透，决定了你能不能在关键时刻纠正 AI

所以在 AI 工作流里，人最重要的不是“做更多体力活”，而是守住这几件事：

• 关键设计想透
• 明确什么是最重要的抓手
• 知道哪些东西 AI 不擅长，但又特别重要
• 在关键决策上，如果发现 AI 不行，要相信自己

理想状态不是“我什么都不看”，而是：

1. 不关心底层所有细节
2. 但对关键点非常清楚

这里还有一个我越来越确定的判断：

用好 AI 的关键，不只是会不会调用模型，而是既清楚 AI 能力的边界，又具备足够的领域知识和经验。

只有这样，人才有可能：

• 设计出真正适合 AI 的工作流程
• 判断哪些任务该交给 AI，哪些不该
• 在 AI 出现偏差时，及时识别并纠正

如果缺少领域知识，你就很难判断结果到底是不是靠谱。

如果不清楚 AI 的边界，你又很容易把它放到不适合的位置，最后把本来能做稳的事情做乱。

说到底，人在这个过程里最重要的作用，仍然是：

• 做出合理的决策
• 纠正 AI 的不足

而这两件事，本质上都非常依赖领域知识。

因为只有真正理解这个领域里什么算对、什么算重要、什么风险不能接受，你才有能力在 AI 看起来“好像也说得通”的时候，识别出它其实已经偏了。

领域知识还有一个非常实际的作用：

帮助你分辨哪些是重要抓手，必须重点审核；哪些可以先交给 AI 展开。

这件事非常关键，因为人在 AI 工作流里最稀缺的不是操作次数，而是注意力。

如果抓不住真正重要的锚点，人就很容易：

• 在不重要的细节上花太多时间
• 对真正关键的约束审得不够
• 要么什么都不放手，要么什么都放手

而领域知识的价值，恰恰就在于帮助你知道：

• 哪些地方一旦错了，整体方向就会偏
• 哪些地方可以先让 AI 铺开，再由人收口
• 哪些地方必须人工拍板，不能默认相信 AI

这也是为什么“懂领域”不只是让你更会评价结果，而是让你更会分配审核力度。

三、AI Coding 里最值得抓的几个锚点

如果你在用 AI 写代码，最该重点关注的不是它生成了多少文件，而是它有没有守住真正重要的约束。

1. 测试

尤其是和设计功能用例直接相关的测试。不是只修一个 case，而是围绕真正的设计需求，补几十条能约束行为边界的测试。

我尤其看重：

• Public API 的测试

因为这些测试最直接决定你对外承诺的行为有没有被守住。

2. 契约层

对外 public 接口的输入输出数据结构，必须清楚。

重点不是“内部怎么拆”，而是：

• 对外 public 接口的输入结构是什么
• 输出结构是什么
• public API 的功能边界是什么

如果契约层不清楚，AI 很容易在实现细节里看起来很忙，但对外行为已经悄悄漂掉了。

3. Examples

这个库到底怎么用，必须有清楚的例子。

Examples 的价值不是“好看”，而是：

• 对外用法更稳定
• 契约更容易被人审核
• AI 自己也更容易被 examples 约束

很多时候，public API、契约层和 examples，其实是一组互相校验的东西。

四、凡是传统程序能可靠做好的，就让传统程序做

这是一个非常重要的原则：

凡是传统程序能可靠做好的，用传统程序做。

因为 AI 擅长的是：

• 模糊匹配
• 启发式推进
• 在不完整信息下给出候选

而传统程序更适合：

• 结构化输入输出
• 稳定规则检查
• 批量一致性校验
• 程序化质检

所以：

• 能结构化接受的，就结构化输入
• 能结构化产出的，就结构化文件
• 链接失效、文档引用、代码和测试的对齐、代码和文档的对齐，这些最好程序化质检

不要让 AI 去承担那些本来就应该交给确定性程序的工作。

本地开发和正式部署，要分开设计

这也是软件工作流里一个很容易被忽略，但非常影响效率的问题：

本地开发环境和正式部署环境，不应该用同一套优化目标。

本地开发阶段，最重要的是：

• 迭代足够快
• 改动后能马上验证
• 不要被漫长安装、远程依赖和重型流程拖慢

正式部署阶段，最重要的则是：

• 稳定
• 可复现
• 可审计
• 可回滚

这两者如果混在一起，常见结果就是：

• 开发时过度追求部署级严谨，导致本地迭代很慢
• 部署时又保留了太多开发期临时做法，导致线上不稳

所以更合理的做法通常是：

• 本地开发环境优先为快速反馈服务
• 正式部署环境优先为稳定交付服务

例如在本地开发里，很多时候应该优先考虑：

• 本地化安装
• 本地缓存依赖
• 更轻量的开发启动方式
• 能跳过就跳过的重型远程流程

因为如果本地验证一轮就要很久，AI 即使能很快展开修改，整个开发节奏还是会被环境拖死。

所以在 AI Coding 里，不只是代码生成要快，本地验证闭环也必须足够快。

否则你得到的不是“AI 加速开发”，而只是“AI 更快地产生等待”。

在软件问题里，不要把 agent 当默认入口

AI 赋能软件，一个非常常见的误区是：

只要问题和软件有关，就默认应该上 AI agent。

这通常是不对的。

任何技术都有自己的适用场景。agent 当然有价值，但它不是默认优先级最高的方案，更不是“看起来高级，所以先用”的方案。

如果一个问题传统程序已经能妥善解决，那么强行交给 agent，通常只会带来这些副作用：

• 更慢
• 更不可靠
• 成本更高
• 一致性更差
• 排查和复盘更困难

原因并不复杂。传统程序依赖的是确定性逻辑；而 agent 依赖的是规划、调用、推断和上下文理解。链路一长，不稳定因素就会显著增加。

所以在软件场景里，判断顺序最好反过来：

1. 先问：传统程序是否能解决？
2. 再问：AI 写一个简单程序，是否就能解决？
3. 前两者都不合适，再问：是否真的需要动用 AI agent 的自主能力？

第二层往往很有价值：让 AI 写临时程序

很多问题并不需要 agent，但非常适合让 AI 帮你快速写一个临时程序、脚本或一次性工具。

这类方式的价值在于：

• 仍然以传统程序作为最终执行体
• 可以把人从重复编码里解放出来
• 比直接放任 agent 自主推进更容易检查
• 更容易补测试、补样例、补程序化质检

但这里也要非常清醒：

不能因为是 AI 写出来的程序，就默认它一定写对。

尤其任务一旦变复杂，就很难保证：

• 一次写对
• 每次都一致
• 边界条件都覆盖
• 长期维护时不漂移

所以更稳的做法不是“相信 AI 写的程序”，而是：

• 把它当成候选实现
• 用样例、测试、校验脚本去约束
• 明确它是否需要可靠性和一致性保证

如果一个任务要求很高的一致性，但你又无法通过测试、契约、固定输入输出去约束它，那就说明这件事还不适合交给 AI 生成代码后直接运行。

一个更稳的软件问题决策顺序

每次要解决一个问题时，我更建议按下面这个顺序思考：

1. 传统程序是否能解决？
2. 如果能解决，直接用传统程序，不要上 AI agent。
3. 如果传统程序暂时没有现成实现，AI 写简单程序是否能解决？
4. 如果要这样做，是否能通过测试、样例、契约、程序化校验来保证可靠和一致性？
5. 只有前面都不合适，或者问题本身就是开放式探索、多步协作、上下文强依赖任务时，再考虑利用 AI agent 能力。

这个顺序背后的核心不是“反对 agent”，而是：

把 agent 放到真正需要它的地方。

只有这样，AI 才是在给软件工作流做赋能，而不是在给原本清晰的问题增加新的不确定性。

五、AI 真正该做的，是先把方向做对

一个很常见的误区是：指望 AI 一次就完成大范围修改，而且每一步都完全到位。

这通常不现实。

更稳的方式是：

1. 先让 AI 把方向正确的工作做出来
2. 不用一开始就关注所有细节
3. 然后针对关键点逐步收口

这背后有一个很重要的认识：

先开发一个完整版本，再去收，不要每一步都先审核到位。

因为很多事情如果在太抽象、太早期的时候就要求完全正确，效率会很低。很多有效思考，反而是在有了一定进展之后才会出现。

所以比“严格的先后顺序”更有效的，往往是：

相互依赖、迭代式收紧

而不是：

先把每一步都审完，再允许下一步开始

这里其实还对应着一个更具体的问题：

人和 AI 怎么交互

很多人一开始和 AI 协作时，会本能地把自己变成“逐步下达每个微动作的人”。

但大多数情况下，这并不是最好的方式。

更稳的交互方式通常是：

1. 大部分时候，提指令，而不是提“怎么做”的细节

也就是说，人更应该说明：

• 目标是什么
• 当前任务是什么
• 验收标准是什么
• 哪些约束不能破

而不是一开始就把每一个实现步骤都替 AI 决定掉。

因为 AI 的价值，本来就部分来自于：

• 它可以自己展开执行
• 它可以自己补齐一部分中间步骤
• 它可以把低层体力活先铺开

如果人一开始就把所有细节都手动规定死，很多时候反而会失去 AI 在执行展开上的价值。

2. 重点关注验收，而不是过度关注 AI 每一步做了什么

这不是说过程不重要，而是说人的注意力要放在更高杠杆的位置。

更关键的是：

• 最终结果是否满足要求
• 关键检查项是否覆盖
• 是否违反了已有约束
• 有没有留下明显风险

很多时候，人并不需要审核 AI 的每一个中间动作细节，而是要重点审核那些真正影响结果质量的点。

换句话说：

• 不要默认去盯住所有过程细节
• 要重点盯住验收和关键事实

3. 重点守住重要约束，比如数据模型和程序架构

人最该重点把关的，通常不是“这一步命令先后顺序有没有完全按我想的来”，而是更重要的结构性约束。

例如：

• 数据模型有没有漂
• public API 和契约层有没有漂
• 程序架构有没有被破坏
• 模块边界是不是还清楚
• 测试是不是还在真正约束行为

这些东西一旦出问题，后面即使局部细节都做得很忙，整体方向仍然可能是错的。

所以更好的姿势往往不是：

• 人盯 AI 的所有微操作

而是：

• 人负责目标、验收和关键约束
• AI 负责铺开执行和展开候选方案

这也是为什么我一直觉得，复杂任务里人和 AI 最好的关系不是“逐步遥控”，而是：

人守住方向、验收和关键设计，AI 去展开执行。

六、技能、Prompt、命令行工具，才是长期收益所在

只靠临场对话，AI 的表现会很不稳定。

更有长期价值的做法，是不断积累这些东西：

• 可复用的 prompt
• 命令行工具
• SKILL
• skillset

它们的价值在于：把一次性的经验，沉淀成下次还能复用的工作流。

为什么 skill 特别有价值

skill 的优势不是“更严格”，而是更灵活。

现实世界里，很多任务和定义并不是完全一致的，但 skill 仍然能让工作继续推进。它不像死板规则那样，一遇到实际情况偏差就彻底停住。

所以好的 skill，不只是“帮你修一个问题”，而是：

• 形成通用规范和指南
• 形成可复用工具
• 让未来的同类问题更便宜

这背后其实是一个更重要的原则：

关注一类问题，而不是只关注一个问题。

解决一个问题，也许只省 5 分钟，但未来还会再花 100 分钟； 解决一类问题，也许这次多花 10 分钟，但未来很多次都只要 10 分钟。

skill 不是单点技巧，而是可组合能力

很多复杂任务并不是一个 skill 能覆盖完的。

这时更合理的做法是：

• 可以一次下达多个 SKILL
• 让多个 skill 联合调用
• 把不同 skill 分别用于不同职责

比如：

• 一个 skill 负责结构审查
• 一个 skill 负责循环化执行 worklist
• 一个 skill 负责复盘和门禁补全

这类组合的价值在于：你不是临场重新发明流程，而是在复用一组已经沉淀下来的工作方式。

七、Context Engineering：把稳定上下文前置

AI 工作流里，另一个非常重要但经常被低估的能力是：

context engineering。

很多人一说上下文，第一反应还是“这一轮对话里补充了哪些背景”。

但在真实项目里，更重要的往往不是临时补几句说明，而是把那些会长期影响决策的稳定上下文，提前沉淀到固定位置。

例如一个项目，至少应该让 AI 知道：

• 这个项目本身是做什么的
• 它直接依赖哪些相关项目
• 这些相关项目分别承担什么职责
• 关键代码、契约、文档分别在哪
• 当前项目遇到跨项目问题时，应该优先去哪里看

这里尤其关键的一类上下文是：

和当前项目直接相关的其他项目。

因为很多项目并不是孤立存在的。

例如：

• 一个前端项目依赖某个后端项目
• 一个 SDK 项目依赖某个协议或 OpenAPI 项目
• 一个 UI 项目依赖某个 design token 或组件库项目

如果这些信息没有提前给清楚，AI 在做很多事情时就会天然缺背景，比如：

• 无法判断应该去哪个仓库找事实源
• 不知道接口 contract 应该以哪个项目为准
• 不知道跨项目改动时应该检查哪些联动点
• 很容易在当前仓库里凭空猜测，最后做出局部合理、整体错误的决定

这类信息有一个很重要的特点：

• 它不是一次性提示词
• 它不是只在某一轮对话里有用
• 它会贯穿整个项目周期

但 context engineering 不只是静态背景信息。

在多 agent 协作里，还有一类非常关键的上下文是：

其他 agent 刚刚改了什么。

也就是说，agent 之间如果能互相看到彼此的修改 diff，就能非常快地知道对方刚改了哪些文件、调整了什么结构、补了什么测试、改变了什么 contract。

这类信息的价值很高，因为它能显著减少：

• 重复分析同一段代码
• 在别人已经修改过的基础上继续按旧假设工作
• 不知道上游输入已经变了，导致下游判断失真
• 协作过程中互相覆盖或互相打架

所以从上下文角度看，除了 AGENTS.md 这类稳定项目上下文之外，协作中的动态变更上下文也很重要。

其中最有价值的一种形式，就是让 agent 能快速看到彼此最新的 diff。

这样一来，agent 不只是知道“这个项目长期是什么样”，还知道“这个项目刚刚发生了什么变化”。

所以这类上下文，最适合放到像 AGENTS.md 这样的稳定入口里。

因为 AGENTS.md 适合承载的，正是这类“项目级、长期有效、反复会用到”的上下文，例如：

• 项目的核心目标
• 仓库结构和关键入口
• 相关项目列表
• 直接依赖项目的路径或定位方式
• 常见联动检查点
• 本地开发和验证方式

这样做的价值不只是“让 AI 知道更多”，而是：

• 降低每次重复解释项目背景的成本
• 减少 AI 因为缺少跨项目上下文而做错判断
• 让 AI 更容易找到真正的事实源，而不是在当前目录里盲猜
• 把上下文工程从临场补救，变成前置设计

所以如果说 prompt、skill、工具是在沉淀“怎么做”，那么 context engineering 更像是在沉淀：

AI 做判断时，应该站在什么背景上理解这个项目。

八、AI 时代的从业者，必须同时理解领域最佳实践和 AI 边界

如果把 AI 真正放进工作流里，你很快会发现，一个新的要求已经出现了：

AI 时代的从业者，需要更广泛地学习领域知识，变成“一专多能”的人。

原因并不复杂。

一方面，你还是要理解所在行业和所在岗位的最佳实践。因为这些最佳实践决定了：

• 什么结果算合格
• 什么流程不能被破坏
• 什么约束是业务里真正重要的
• 哪些经验是长期被验证过的，而不是临时拍脑袋

如果连行业本身的成熟做法都不清楚，那你就很难判断 AI 给出的方案到底是在提效，还是在制造新的风险。

这里还有一个很重要但经常被低估的现实：

工程师依然非常重要。

因为很多系统本身，它的领域知识就不是某种“脱离技术实现的业务常识”，而就是开发知识、算法知识和系统设计知识本身。

例如这类平台型系统：

• 软件研发平台
• 运维部署平台
• 计算平台

在这些系统里，你很难把“领域知识”和“工程知识”彻底分开。

因为这个领域里真正重要的问题，往往就是：

• 开发流程怎么组织才合理
• 部署链路怎么设计才稳定
• 资源调度和任务编排怎么做才高效
• 哪些架构约束不能破
• 哪些算法和数据结构选择会直接影响系统能力边界

也就是说，这类系统的领域专家，很多时候本来就是工程师。

所以 AI 时代并不是“只要会提需求，工程细节都可以交给 AI”。

相反，越是这类平台型系统，越需要真正懂开发、懂系统、懂算法的人来做判断、做设计、做验收。

另一方面，你又必须理解 AI 的能力边界。你要知道：

• 它在哪些任务上已经非常强
• 它在哪些任务上容易出现系统性偏差
• 什么适合交给 AI 先做
• 什么必须由人把关、复核和拍板

真正有价值的，不是简单把旧工作流原样搬给 AI，而是基于 AI 的能力边界，对现有工作方式做出合适调整。

比如：

• 原来完全靠人工整理的信息，现在可以先让 AI 做第一轮归纳和展开
• 原来依赖经验判断的部分，要补上更清楚的验收标准和边界约束
• 原来默认由人串行推进的流程，可能要改成“AI 先铺开，人后收口”的协作方式
• 原来只要求会做单点任务的岗位，现在更需要能横跨业务、工具、流程和质量判断的人

所以 AI 时代真正稀缺的，不只是“会不会用 AI”，而是：

• 既懂领域
• 又懂方法
• 还懂 AI 适合放在哪里

只有这样，AI 才不是一个看起来很聪明的玩具，而是真正能最大化解放个体生产力的工具。

九、AI 使用中的关键动作：观察、纠正、复盘

AI 的价值不只是“让它做事”，而是要持续观察它是怎么做事的。

关键动作有三个：

1. 观察 AI 在做什么
2. 纠正偏差
3. 讨论为什么它没有按要求做，并改进 prompt / skill / tool

这里尤其值得讨论和改进的，通常有两类情况：

1. AI 没有按照约定的规则做
2. AI 做出了自己不合理的做法

这里最需要防止的是：

• 无脑接受，直接触发下一步工作

因为一旦流程没有“停下来对事实做判断”的环节，错误就会一路扩散。

这里尤其有两个危险信号：

1. 被动等，无事可做
2. 没有任何掌控感

一旦进入这种状态，说明流程设计本身有问题。不是 AI 太弱，而是人已经不再基于事实工作。

十、过程指标必须被显式要求出来

AI 工作不能只盯最终结果，还要看过程指标。

你需要强制它产出：

• 过程中的事实
• 当前检查了什么
• 哪些地方还没覆盖
• 哪些判断只是推测

举个很典型的例子：如果文件组织结构不符合逻辑，只给一个“已经整理好了”的结论是没有意义的。你必须让 AI 把结构索引、检查依据、问题节点显式说出来。

这也是为什么生成的文档，人必须审核得过来才有意义。

如果一个产物大到人根本无法有效审核，那这个产物本身就已经失去价值了。

十一、并行很重要，但不要滥用

AI 很适合并行，但并行也要有边界。

比较合理的配置通常是：

• 1～2 个不需要太多人介入的任务
• 1 个需要人仔细审核的任务

也就是说，不是所有东西都一口气并行出去，而是把人类注意力放到最需要审的那个任务上，同时让其他任务在旁边推进。

这能同时兼顾：

• 效率
• 掌控感
• 审核质量

十二、不要指望 AI 一次改大范围就全对

这一点在文档和代码上都成立。

重要工作最好控制范围，一个一个进行。比如：

• 文档逻辑核对
• 信息结构审查
• 关联对齐

这些事情如果一次改太大，人很容易失去审核能力，AI 也更容易做出糟糕决策。

所以复杂任务里，更好的策略通常是：

• 范围收小
• 每轮独立 context
• 显式的 for 循环或 while 质检
• 每轮独立验收

尤其像逐一核对文档这种任务，更需要程序化和循环化的质检，而不是一次性祈祷 AI 全做对。

这类工作往往还有一个特点：

• 人参与度不高
• 很耗时间
• 特别适合长时间自主运行

例如：

• 信息结构核对
• 关联关系对齐
• 链接失效扫描
• 文档和代码引用关系检查

这些都更适合被拆成显式循环，让 AI 在每一轮独立 context 下推进，再用传统程序做程序化质检。

十三、越早实战，越能避免空想设计

AI 时代一个非常重要的变化是：

要尽早进入实战。

因为很多认知，如果没有真实推进，就只能停留在空想设计。

你只有真的：

• 用 AI 写代码
• 用 AI 改文档
• 用 AI 做质检
• 用 AI 做复盘

才会发现：

• 自己原来理解有误的 coding 知识和概念
• AI 原来会反复做出的糟糕决策
• 哪些 prompt 根本不够用
• 哪些 skill 其实缺了门禁和检查清单

2025 年很多人和 AI 一起 coding 的最大收获，往往并不是“它帮我多写了多少”，而是：

• 纠正了大量自己之前不知道或理解有误的知识
• 同时也纠正了 AI 大量糟糕的决策

这两件事是一起发生的。

十四、复盘不是可选项，而是 AI 工作流的一部分

AI 会重复犯某类错，人也会重复用错 AI。

所以一旦出现“我已经让你核对过几次，你都没发现”的情况，最有效的动作不是情绪化，而是做一次 Decision Retrospective。

这个动作的价值在于：把问题从“这次怎么又错了”升级为“为什么同类错误会重复发生”。

这里有一个非常关键的思路转变：

不要只想着修复一个问题，而要优先识别这背后是不是一类问题。

因为如果你盯着的是“把这次错的地方补上”，那很容易停留在一次性的局部修补：

• 这次把漏掉的字段补了
• 这次把漏跑的检查补了
• 这次把 prompt 再改一句

但这些动作本身，并不等于能力升级。

真正更有价值的动作是继续追问：

• 这次暴露出来的到底是哪一类问题？
• 是检查面总在收缩？
• 是规则只存在于文档里，没有变成执行入口？
• 是 prompt 说了原则，但没有给最小动作？
• 是 skill 写了约束，但没有配套 grep gate、checklist 或固定命令？

当你开始这样看问题，你做的就不再是“修一个 bug”，而是在识别一类会反复出现的失误模式。

这时候，复盘的目标也应该随之改变：

• 先找根源原因
• 再把解决方案固化下来
• 最后把它变成自己处理同类问题的新能力

这个“固化”非常重要。因为很多经验，如果只停留在脑子里，下次换个上下文、换个任务、换个 agent，很快又会丢。

更稳的做法是把它落进明确的载体里，比如：

• 写进 prompt，让模型一开始就被约束到正确检查面
• 写进 skill，让要求从“临场提醒”变成“默认工作流”
• 写成命令行检查工具或最小命令清单，让核对动作程序化
• 写成 checklist / gate / fail-fast 规则，让遗漏变得更难发生

只有这样，你才不是在被动修补一次错误，而是在主动升级自己处理这一类问题的能力。

一个典型复盘应该至少回答这些问题：

• 预期是什么？
• 实际发生了什么？
• 哪些检查项被漏了？
• 是用户指令不清、上下文不足，还是执行失误？
• 缺的是文档、流程、还是门禁？
• 下次怎么把它固化成 checklist / grep gate / 最小命令清单？

真正高价值的复盘，不是“承认错了”，而是把错误流程化、门禁化，避免同类漏检重复出现。

一个典型案例是：skill 明明写了，为什么还是连续漏检。

这类复盘最有价值的地方，不是抽象地说“以后更仔细”，而是把真实案例拆开。

比如有一次合规核对，用户已经多次明确要求“按 python-implementing-mode 核对是否合规”，理论上应该完整覆盖 skill 里的所有硬规则，包括：

• getattr
• hasattr
• setattr

但实际执行时，前几轮只检查了这些内容：

• Any / object
• 动态 import
• 字符串类型注解
• __all__
• 文件长度
• ruff / pytest

结果就是：getattr / hasattr / setattr 这条明明写在 skill 里，却连续几轮都漏掉了。

这类问题的根因，通常不是：

• 用户没说清
• 上下文不够
• 环境阻碍

而是更具体的执行失误：

• 把核对过程错误收敛成“最近争议最大的几条”
• 复用了上一轮的心理范围，没有重新从 skill 文本拉完整检查面
• 没把 skill 规则操作化成 checklist / grep gate / 最小命令清单

所以真正该做的，不是继续靠记忆核对，而是把它固化成门禁。比如：

rg -n '\b(getattr|setattr|hasattr)\s*\(' src
rg -n 'importlib\.import_module|spec_from_file_location|exec_module' src
rg -n '\bAny\b|typing\.Any|#allow object|: object\b|-> object\b|\bobject\]|\bobject \|' src

再往前走一步，应该把这种经验直接回写到 SSOT 或 skill 本身，比如给 python-implementing-mode 增加“合规核对最小必跑检查清单”。

这才叫真正的复盘闭环：

• 不是只知道错了
• 而是知道为什么会重复错
• 最后把错误从“记忆问题”改成“流程问题”

十五、什么工作适合长时间自主运行

有一类工作，人参与度不高、很耗时间，而且非常适合 AI 长时间自主运行：

• 文档结构核对
• 文档对齐
• 代码和文档的对齐
• 代码和测试用例的对齐
• 链接与引用关系检查

这些工作如果能被结构化和程序化，就特别适合 AI 长时间跑。

但要注意：

• SSOT 定义必须人工核对

因为 AI 无法真正自检“是否对齐到真源”。少量错误都会引发严重影响。

所以这里的边界非常清楚：

• 对齐、扫描、枚举、粗筛，可以尽量自动化
• 真正的 SSOT 定义和关键设计，必须由人守住

十六、关键设计想透，比 AI 协助比例更重要

不管 AI 参与比例是 20% 还是 80%，真正重要的是：

• 关键设计你自己要想透
• 重要抓手你要找出来
• 能定义清楚的地方要尽量定义清楚
• 文档和测试要强绑定
• 尽量减少“设计 → 实现 → 测试”的链路长度

如果这些没守住，再高的 AI 参与度也只是在更快地产生偏差。

十七、复杂任务里，AI 更适合“参谋 + 讨论”

复杂任务中，AI 最可靠的定位其实就是：

• 参谋
• 讨论对象
• 帮你展开多个候选方向
• 帮你跑程序化检查和长时间任务

但最终关键决策如果发现 AI 不行，就要相信自己。

这不是反 AI，而是对 AI 的能力边界有清楚认识。

要真正把 AI 用好，最后都要落到三件事上：

1. 了解能力边界
2. 找到重要抓手
3. 形成工作流

而这些东西，没有大量实践根本长不出来。真正的进步，几乎都来自大量实战、不断纠偏、持续复盘。

结语

AI 最危险的误用，不是“它犯错了”，而是人把自己的判断权让渡出去了。

所以我越来越相信，复杂工作里最稳的姿势不是“AI 全自动”，而是：

• AI 先做方向正确的工作
• 人持续观察、纠偏、复盘
• 传统程序承担确定性工作
• 技能、prompt、工具沉淀成长期资产
• 关键设计和 SSOT 仍然由人把关

AI 最适合做参谋，而不是指挥官。

当你开始从“修一个问题”转向“解决一类问题”，从“让 AI 替我做”转向“让我和 AI 一起形成更好的工作流”，它才会真正成为能力放大器，而不是噪音制造器。