为什么现在要讲这件事
AI coding 的关键变化不是“补全更准”，而是模型被放进了能观察、行动、验证的软件工程环境。
幻觉不是偶发 Bug，而是生成式模型的结构性风险
LLM 的训练目标使它擅长生成“看起来合理”的延续，但事实正确性需要外部证据、上下文约束和验证机制共同支撑。
LLM 的基本动作
输入被切成 token，模型根据上下文计算下一个 token 的概率分布。连续选择 token 后，用户看到的是自然语言、代码或结构化结果。
- 它不是默认先查数据库再回答。
- 它会把上下文中最像答案的模式补全出来。
- 当知识稀疏、提示含糊或上下文污染时，错误也会被流畅表达。
知识不完整或过期
训练语料是历史快照，低频事实、新版本 API、内部私有代码都可能不在模型可靠分布里。
训练和评估激励
如果评测只奖励答对而不奖励承认不确定，模型会倾向于猜测。OpenAI 公开研究把这一点列为关键因素之一。
上下文与采样
冲突资料、错误提示、过高温度、缺少证据边界，都会让模型沿着“像答案”的方向偏移。
| 幻觉表现 | 在 coding 中的具体样子 | 有效控制手段 |
|---|---|---|
| 编造事实 | 声称某个依赖、接口、配置项存在，但仓库里没有。 | 先搜索仓库和官方文档，再写结论；引用文件路径或来源。 |
| 误读上下文 | 只看相似文件就套用模式，忽略项目约束。 | 读取入口、调用链、测试和约定文件，避免局部猜测。 |
| 自信错误 | 补丁能解释得通，但测试、编译或运行失败。 | 强制 inspect-edit-test 循环，把环境反馈纳入下一轮。 |
| 引用幻觉 | 给出不存在的论文、参数、版本号或链接。 | 权威来源优先；无法查证时明确标记“不确定”。 |
避免幻觉靠工程约束，不靠祈祷
一句“不要幻觉”只是软约束。可靠做法是把模型输出放进证据、工具和验证的闭环里。
评估模型：没有单一“最好”，只有任务匹配
内部选型不要只看榜单截图。要把模型能力拆成通用推理、代码、工具调用、长上下文、成本、延迟和安全边界。
| 评估对象 | 代表 benchmark | 能说明什么 | 局限 |
|---|---|---|---|
| 通用知识/推理 | MMLU-Pro、GPQA | 跨学科知识和高难推理能力。 | 不等于企业内部任务表现，也不等于工具使用可靠性。 |
| 函数级 coding | HumanEval、MBPP | 短函数生成和单元测试通过率。 | 离真实仓库、多文件修改和需求澄清较远。 |
| 新鲜代码题 | LiveCodeBench | 降低训练污染，覆盖生成、自修复、执行预测等代码能力。 | 仍偏竞赛/题目，不完全代表业务仓库。 |
| 真实 issue 修复 | SWE-bench Verified / Pro | 仓库级定位、修改和验证能力。 | 公开集会污染；OpenAI 已指出 Verified 对前沿模型区分度下降。 |
| 人类偏好 | LMArena | 匿名对战下的主观使用体验。 | 偏对话偏好，不能替代工程验收。 |
Agent 的本质：模型驱动的行动循环
Agent 不是神秘概念。它是一个控制循环：观察环境，推理下一步，通过工具行动，读取反馈，再决定继续或停止。
生成能力
负责语言理解、代码生成、解释和计划候选项。
行动循环
决定什么时候读资料、调用工具、修改环境、停止并汇报。
运行外壳
提供上下文组装、工具协议、权限、状态、日志和错误恢复。
工程专用外壳
面向仓库、diff、终端、测试、Git、CI 和代码审查做优化。
一个简单 Coding Agent 的原理
主流 AI coding agent 工具的核心不是“自动写代码”，而是把模型放进 inspect-edit-test 的工程循环。
不是越多越好
Harness 要选择相关文件、压缩历史、保留约束，否则长上下文会带来噪音和冲突。
行动需要边界
读文件、写文件、跑命令、联网、删除、发布应该有不同权限级别和审批策略。
测试是事实源
编译器、单测、集成测试、运行日志比模型自我解释更有约束力。
Skill 和 SubAgent：把个人经验变成团队能力
Skill 解决“同类任务反复提示”的问题；SubAgent 解决“任务可拆分、可并行、可独立验证”的问题。
可复用能力包
一组任务说明、脚本、模板、示例和资源。它让 agent 在特定任务上按团队沉淀下来的流程行动。
- 代码审查 checklist
- 发布流程和回滚脚本
- 内部文档写作模板
- 项目常用命令和边界条件
受限 worker
为一个明确子任务启动的独立 agent，有自己的目标、上下文、工具权限和交付格式。
- 并行阅读不同模块
- 独立查外部资料
- 专门复现测试失败
- 作为 reviewer 验证主 agent 结论
内部落地建议：把 AI 当成可验证的工程协作者
不要把 agent 当成无监督实习生，也不要只把它当代码补全。正确姿势是给边界、给资料、给验证、给可回滚的工作单元。
小而可验收
把需求拆成明确输入、输出、约束、验收命令和风险边界。
结论必须能追溯
涉及事实、API、版本、外部政策时，必须引用官方文档或代码位置。
降低回归面
让 agent 优先做局部、可审查、可回滚的补丁，而不是顺手大重构。
每轮都有反馈
能跑测试就跑测试；不能跑时说明原因，并给出替代验证。
高风险动作审批
删除、发布、迁移数据、发外部消息、改权限等必须人工确认。
用 Skill 固化流程
把成功经验写成 skill、模板、检查清单和项目指令，减少下次从零提示。
权威资料与推荐阅读
下面的资料用于支撑本文的核心论点，优先选择论文、官方文档和 benchmark 官方页面。