在 AI 时代，我们看到很多关于“AI 写代码提效”的案例——包括我自己之前写过的《AI IDE开发提效体验：以某功能模块需求变更开发为例》。那篇文章展示了在明确输入、清晰需求、合理分解任务的前提下，用 AI IDE 组合完成二次开发在某阶段显著提效的体验。
但在 真实联调与集成阶段，我遇到的情况却是一个几乎正好相反的现实：
AI 帮忙写出来的代码大部分看起来可用，但却引发了更多的不确定性与调试成本，不仅没有降低整体工时，反而增加了实际调试时间。
这让我开始重新思考：
AI 在软件二次开发中的真正价值究竟是什么？
它能带来“质变”吗？如果能，是在什么条件下？
如果不能，我们应该如何更高效地协作，而不是盲目期待“AI 替代人”？
AI 输出的代码看似可用，但集成联调并未提效
在嵌入式项目的集成调试阶段，我明显感受到以下几类问题不断出现：
- 误用宏定义导致逻辑错误
AI 不了解某些宏定义是仅在特定版本下有效的，会错误地将它们应用到当前目标产品代码，导致编译错误或运行逻辑异常。 - 协议实现与规范不一致
尽管输入了协议规范文档，AI 仍产生实现细节与规范不一致的代码，这在协议处理流程中往往会导致运行时错误。 - 业务代码结构错误
比如在定时器模块中填错入参格式、误用状态机逻辑等问题，这类错误往往需要工程师在实际硬件上调试才能暴露。 - 多硬件平台联调的复杂性
主从节点版本不同，AI 生成的逻辑不能同时满足两端要求，导致需要大量人工逐段修复。
综合来看，这些错误不是“单纯写代码写慢”的问题，而是AI 在忽略上下文边界、错误推断语义、对边缘条件处理不当时产生的隐性成本。而这部分错误，往往只有在真实硬件上才能暴露。
因此：单纯依赖 AI 写代码 + 实际联调在多数情境下不但没有缩短整体工时，反而延长了实际调试周期。
这已经不是“辅助开发有没有效果”的问题，而是“AI 在工程级任务中如何处理不确定性”的问题本质。
不确定性 × 过程 vs 结果
要理解这一现象，我们需要从一个更根本的角度审视 AI 的输出机制。
AI 的输出总伴随着一个不确定性（uncertainty）。在统计和生成模型中，这种不确定性是内在的特性，它来自概率估计和语言模型的近似推断。AI 的每条建议或代码片段都有一个隐含的“概率层面正确度”，这个正确度并不等同于工程级的确定性。
而软件工程里真正的“安全感”不是写对每一行代码，而是最终行为与预期一致，这是一种“结果确定性（result certainty）”。
简而言之，这种确定性的差异可以描述成：
- 过程确定性是传统工程师在每一步设计中控制逻辑
- 结果确定性是通过定义验收标准并允许系统自己试错直到满足标准来确认结果是正确的。
在 AI 编码场景下，这两种确定性的差异尤为重要：
| 模式 | 核心逻辑 | 优点 | 限制 |
| 过程确定性 | 人类定义每一步行为 | 精准可控 | 难适应大规模未知结构 |
| 结果确定性 | 明确验收标准，让系统反复试错直到满足 | 当标准能形式化时效率高 | 标准难定义、错误反馈难捕获 |
在前期写代码阶段，我们更偏向过程确定性：
我知道每一条逻辑应该怎么写。
但在联调阶段，AI 不能像人一样理解全部隐含设计假设，而只能基于局部信息推断，这意味着它很难做到过程上的精准控制。
AI 在二次开发中最适合扮演什么角色？
综上观察与分析，我得出的判断如下：
结论一：
AI 本质上是一个概率推断系统，而不是一个过程定义系统。
它能在输入清晰、规范完备、需求边界明确的情况下生成大体正确的代码，但它无法保证对“边缘条件、隐性假设、复杂上下文关系”的理解。
这直接导致了前面观察到的多类错误。
结论二：
AI 在二次开发中真正增加价值的不是写代码，而是帮助工程师识别和构造出“正确的边界与验收标准”。
技术规范、验收条件、前置假设等工程边界，是决定 AI 输出是否可靠的关键变量。
若没有明确可验证的标准——
AI 可能生成完美结构的代码，但它内部逻辑并不满足规范细节，最终仍需人工重构。
边界条件与风险
⚠️ 使用场景边界
本策略对以下情况更适合：
- 输入资料完整（设计文档、历史决策、规范、示例等）
- 验收标准可以形式化（测试用例、静态检查规则等）
- 目标业务逻辑是确定性的，而非开放式推断
不适用或风险更高的情况包括：
- 隐含约束未记录，AI 无法推断上下文
- 多平台逻辑相互交织、条件差异无法统一表达
- 需要深度系统级联调和硬件交叉验证
如何与 AI 更高效协作
既然 AI 本身不是问题，但我们要和它协作更高效，就需要做两件事：
1) 从需求定义转向“结果契约定义”
不要只是描述你想让 AI写什么，而是定义什么样的输出才算正确。例如：
- 编译无错
- 通过自动化测试
- 符合协议测试样例
- 在特定硬件上运行多次稳定
2) 用自动化测试和验证来作为 AI 的反馈环
不要让 AI 只给出源码，而是在同一个体系内：
- 给出代码
- 自动运行单元/集成测试
- 反馈失败信息给 AI
- 让 AI自我修正
这种循环比盲目写代码更有工程确定性。
3) 适当利用更成熟的 IDE + Agent 工具
虽然工具本身不是万能，但在“运行时层支持闭环反馈”和“契约层验证”能力更强的 Agent（如 Claude Code / Cursor Agent 等）上构建循环，会比单纯用 API 更可靠，因为它们更容易与系统边界集成。
结语
AI 在软件二次开发中并不是万能的速成器。它做得好的，是缩短认识边界、释放阅读代码和构建初版实现的时间；做得差的，是理解复杂工程上下文和控制工程级别准确度。
真正的工程效率来自对 不确定性的管理，不仅仅是编码速度。
换句话说：AI 能加快你的发现，但并不能自动保证结果是真正符合业务需求。
所以我们应该把精力放在定义什么是正确上，而不是让 AI 频繁地产生新的不正确。
了解 实践笔记 的更多信息
订阅后即可通过电子邮件收到最新文章。