外观
AI Coding 认知控制实践手册
柏林ACS · 2026-09-01 · 读完约需 7 分钟
一位开发者说：“我总觉得 AI 写的代码有坑，但没办法去看代码，我现在都懒得看代码。”
下面是一份 AI Coding 速查手册，帮助你在不同任务里决定需要多少控制。
控制不必一开始就做到最严格：先确认问题，再按风险补充审查和验证。
1. 总模型：按任务调整控制
AI Coding 没有一条适用于所有任务的固定流水线。
需要多少检查和确认，主要看任务的确定性、复杂度、影响范围和失败成本。这里的四个维度用于判断风险，不是理论的四层搜索模型。
开始任务前，先看四件事
开始任务时，不必回答一大堆问题，先看四件事：
| 维度 | 低 | 高 |
|---|---|---|
| 确定性 | 问题和方案明确 | 问题/根因不明确 |
| 复杂度 | 单点修改 | 多模块/系统设计 |
| 影响范围 | 局部 | 核心链路/全局 |
| 失败成本 | 容易恢复 | 难以恢复/严重后果 |
如果多个维度都落在右侧，就要增加控制；只有一个维度偏高时，再结合任务的可逆性和现有证据判断。
2. 六条基础规则
下面六条规则，是这份手册的核心。
规则 1：先明确目标，再决定方案
当任务描述直接给出方案时，先确认它想达到什么结果。
例如：
text
“把这个接口改成异步。”这句话说的是方案。真正要解决的，可能是响应太慢、请求超时，或并发能力不足。目标不同，适合的改法和验收标准也不同。
因此，思考顺序应该是：
不要拿到一个方案就直接开始实现：
方案可以随验证结果调整，目标和验收标准要保持清楚。
规则 2：分清现象和原因
看到异常时，把现象和根因分开。在根因不明的排障任务中，至少区分：
如果根因已经明确，可以直接修改。如果根因不明确，先排查或验证。
原则：
问题还没弄清楚，就先补信息，再动代码。
这与 Agent 搜索治理协议 中的“问题建模优先”直接对应。
规则 3：重要判断要有证据
AI 可以先给出假设，但假设不能直接当成事实：
准备采纳一个重要结论时，至少要说清楚：
text
结论是什么？
依据是什么？
证据在哪里？
如何验证？
是否已经验证？特别注意，AI 自己生成的解释、置信度和理由，都仍然属于待验证信息：
“置信度 95%”不是证据。
这对应 Agent 搜索治理协议 中的“证据驱动判断”。
规则 4：每次排查都要有新结果
每一次排查或实验，都要能回答一个问题：
这一步完成之后，我们比之前多知道了什么？
排查或实验至少要带来一种新信息。已经确认的执行动作，则要有可检查的结果：
text
确认一个可能性
排除一个可能性
缩小问题范围
验证一个假设
获得新的事实如果连续几次操作：
说明问题没有收敛。这时先停下来重新建模，避免继续堆修改。
这对应 Agent 搜索治理协议 中的“搜索必须收敛”。
规则 5：改动越大，检查越要充分
小修改可以快速完成；遇到下面这些情况，就要增加审查和验证：
text
跨模块
核心链路
架构变化
数据迁移
性能优化
安全相关
不可逆操作可以把关系理解为：
复杂任务不能只看“代码已经通过编译”，还要确认实际结果和风险。
规则 6：维护认知状态
在复杂任务中，维护一份状态记录，随时更新已经确认和仍待确认的内容。至少写清楚：
text
已经知道什么？
还不知道什么？
当前假设是什么？
验证过什么？
排除了什么？
当前正在验证什么？否则 Agent 很容易：
或者出现：
这份记录能避免 Agent 重复走已经失败的路径，也避免根据已经排除的原因继续修改。
这对应 Agent 搜索治理协议 中的“维护认知状态”。
3. 什么时候需要增加控制
不必每次都执行全部规则。
下面这张表可以帮助你快速选择控制方式。四个判断项只用于估计风险，不替代四层搜索模型。
| 任务状态 | 推荐控制 |
|---|---|
| 明确的小修改 | 直接执行 + 基础验证 |
| 明确 Bug，根因清楚 | 修改 + 验证 |
| 问题明确但根因未知 | 问题建模 + 排查 |
| 多方案选择 | 方案比较 |
| 性能/成本/质量优化 | 实验验证 |
| 复杂架构设计 | 方案分析 + 边界分析 |
| 核心系统修改 | 完整审查 + 验证 |
| 输入信息优化 | 对比实验 |
| AI 连续猜测 | 停止行动，重新建模 |
例如，局部且根因明确的样式修改，通常做基础验证就够；根因不明、影响核心链路的改动，则应先建模、找证据，再决定是否修改。
4. 三类最常见的控制场景
4.1 问题不清楚：先建模
使用：
text
现在先不要修改代码。
请明确：
1. 当前观察到的现象
2. 已确认的事实
3. 尚未确认的信息
4. 当前可能的原因
5. 最需要解决的问题
6. 下一步如何验证等问题和验证方式基本明确后，再让 AI 进入实现。
4.2 方案不确定：先比较
当有两个或更多可行方案时，先让 AI 列出：
text
当前方案
主要替代方案比较：
text
实现成本
复杂度
性能
可靠性
扩展性
维护成本
当前业务适配度比较后记录：
text
当前推荐方案
选择原因
主要代价
适用边界这里不必追求行业最优解，只需说明：
重要替代方案及其代价已经纳入比较。
已有系统通常更看重风险和兼容性；新项目可以更看重实现速度和试错成本。
4.3 优化问题：先实验
这类任务的共同点是：你知道哪里需要改善，却还不知道哪种改法有效。
例如：
text
Prompt 太长
Context 太大
Token 太高
分析质量不稳定
响应太慢直接修改的路径是：
更稳妥的路径是：
以输入信息优化为例，可以拿原文、结构化信息和压缩信息做对照，比较分析质量、Token、总成本和稳定性。
最后要看整体结果：单项指标变好，但质量、成本或稳定性变差，不能算优化成功。
5. 高风险任务：先找可能出错的地方
不是每次改代码都要做这一步。
当任务影响范围大、方案复杂或失败代价高时，可以先让 AI 专门寻找问题，再决定是否修改。
可以让 AI 按下面的格式检查：
text
现在不要修改。
假设当前实现存在问题，
主动寻找最可能失败的地方。
重点检查：
- 需求遗漏
- 未确认假设
- 边界条件
- 异常路径
- 现有功能影响
- 模块间影响
- 测试缺口要求：
text
具体问题
+
代码位置
+
原因
+
验证方法让 AI 发现问题时，先不要同时修复。否则：
代码会不断变化，却很难判断哪次修改解决了什么问题。
先把问题列出来，再决定哪些值得处理。
6. 验证：别只听 AI 的解释
验证就是用运行结果、测试或数据来检查判断是否成立。常见的验证有三类，使用顺序按任务决定。
第一类：确认代码能运行
text
编译
Lint
Unit Test
Integration Test
E2E回答：
代码能否按预期运行？
第二类：确认判断是否正确
text
A/B
对照实验
最小变量实验回答：
我们对问题的理解对不对？
第三类：确认系统是否真的变好
text
质量
成本
性能
稳定性
维护复杂度回答：
这次修改是否真的改善了系统？
三类验证解决的是不同问题，不能互相替代。
7. 哪些地方需要人来拍板
AI 更适合承担这些工作：
text
大量搜索
快速实现
快速比较
快速测试这些判断仍由人负责：
text
问题定义
目标确定
约束确定
价值判断
承担后果
最终决策因此，不必平均地盯着每一步。
优先盯住同时具备以下特点的任务：高影响、高不确定、缺少证据。
可按下面方式分配：
这样分配注意力，通常比逐行检查更有效。
8. 需要完整控制时，按这五步走
如果任务复杂或风险较高，可以按下面的循环推进：
写：先把任务说清楚
明确：
text
目标
范围
约束
验收标准攻：主动找可能的问题
假设当前实现有问题：
text
找遗漏
找反例
找边界
找副作用
找回归证：把猜测变成可验证的问题
把：
text
猜测变成：
text
可验证的问题验：用测试和数据检查
使用：
text
测试
运行
实验
数据获得外部反馈。
判：决定是否交付
最后由人判断：
text
是否解决了真正的问题？
结果是否满足目标？
风险是否可接受？
是否值得继续？9. 开始任务前，快速过一遍
下面这张图适合在任务开始前快速扫一遍。
10. 使用顺序
遇到编码任务时，先判断任务状态，再选择控制方式。简单且明确的任务直接执行并做基础验证；问题不清楚时先建模；方案有分歧时先比较；结果缺少证据时补验证。验证未通过，就回到上一步，重新检查假设或问题，避免无记录地换方案。
最核心的六句话
问题没搞清楚，不要急着解决。
先确认要解决什么，再决定怎么改。
假设可以行动，结论必须有证据。
排查和实验要减少不确定性，执行动作要有可验收结果。
影响越大，通常越需要充分验证。
不同任务需要的控制强度不同。