*——转身：从真实需求长出来的老项目维护技能库*

> 这是《嵌入式 AI 落地手记》的第三篇。上一篇讲了新体系怎么失败的：目标贪多，模板膨胀，试用停在需求和设计两步。这篇讲之后的事——AI 第一次在真实项目里完整跑起来，不在新体系上，而在一个不起眼的地方：老项目维护。

## 一张变更通知单

新体系的试用停下来之后，工作没有停下来。我们手里压着一批老项目，客户的需求变更照常来：一张变更通知单，配上更新过的几份文档——功能规范、接口定义、配置规范，加起来几百页 PDF。

这类活干过的人都知道它难在哪。要改的是老代码，写它的人可能早就不碰了；变更本身往往不大，影响面要自己去翻；几百页文档里真正变的只有标出来的那几处；改完还要担心别的东西被碰坏。当时我们还有一层自己的压力：新体系失败，积压了一批 PR 和需求评审，变更又来得频繁，人有些应付不过来。

同时我心里攒着一批想法。新项目试用那两个月，体系虽然失败了，但"AI 该怎么参与开发"这件事我隐约摸到了一些东西，一直没有机会验证。新体系太大，改不动了；维护场景刚好小、高频、真实——先在这里把想法验一遍，走通了，回头重构新体系也有底。

## 一周搭出来的小东西

九月初，我用大约一周时间搭了一个老项目维护用的技能库。构建方法本身也值得说：先和 AI 讨论出一个合理的流程，把前一阶段的思考落进去；搭完不急着发布，先找一个此前由人完成的变更，让 AI 照流程重做一遍，拿回放结果改技能；改过之后才放出去用。提交记录里留着当时的原话：拿两个已交付的项目自验证了一遍，"基本合理"。第一版敢拿出来给人用，依据就这四个字。

整个库只有五个技能、七百来行。流程五步，不许跳步：

1. **建档**：需求文档统一转成文本，建索引和项目概况。原则是索引先行、按需加载——AI 只读索引定位到的章节，禁止通读全部文档。这条是从上次失败里长出来的：读原始文件太吃上下文。
2. **需求理解**：把这次变更涉及的需求点逐条对照代码现状。
3. **影响与假设**：分析改动影响面，并把所有假设、推测、不确定的地方列成一份清单。
4. **实施**：按确认过的方案改代码。
5. **验证归档**：编译、静态检查、生成测试用例、写变更记录。

流程里有两道必须人过的闸。第一道在假设清单：AI 把清单列出来，人逐条确认，没确认完的假设不许带进实施。第二道在方案：修改方案必须明确批准才算数——技能里的原文是，对假设清单的回答、对方案的沉默，都不构成批准。

为什么要两道闸？这是第一次失败换来的认识：人和 AI 的协作界面在决策上，不在编辑上。与其让人在 AI 生成的几百行文档里通读找错，不如让 AI 先把自己不确定的地方交出来，人只审这些点。

## 先和人比一场

发布前的那次回放验证，后来成了很有价值的材料。做法是：找一份已经由人完成的变更，原始需求文档原样喂给技能库，让 AI 完整跑一遍流程，再拿两版实现对比。同一份需求，两条路径，各做各的。

流程留痕是完整的：二十一条假设逐条列出、逐条经人确认，其中四条按意见做了修改；生成四十五条测试用例；变更记录里逐块核对改动和需求的对应关系；编译零错误，静态检查零新增问题。

实现上的对比更有意思。两边都把功能做了出来，核心控制逻辑一致——那个关键设计最初是 AI 在假设清单里提出、经人确认定下的，人工版本用的也是同一个思路。差异在风格和覆盖面上：AI 用一个参数化结构同时处理两个通道，三百多行；人工实现写成了独立模块，接近一千行，代价是其中一组函数几乎是复制粘贴的两份。反过来，人工版本忠实实现了文档里一条很具体的收发约定；AI 把它简化成了语义近似的写法，意思差不多，但没有照着字面做。AI 又多做了另一件事：给配置值加了一层合法性校验，人工版本没有。

谁赢了？我不打算下这个结论。对我重要的是另外两点：一是没有出现人工版本纠正 AI 逻辑错误的情况；二是 AI 漏掉的是"文档字面要求"这类东西——这正是那道假设确认闸存在的理由，AI 的每个简化决定都摊开在清单里，人在确认时有机会抓住它。

## 真实项目里的两次试用

第一次真实试用是一个功能变更：一个报警功能的使能条件，从诊断接口控制改成配置报文控制。实际用下来，反馈是需求理解和修改都完成得很快。验证链是完整的：编译零错误、静态检查零新增，十六条测试用例全部通过。过程中人对一处逻辑提出过疑问，逐跳核实加回归之后排除了。疑问被认真对待，而不是被流程吞掉，这也是流程设计的一部分。

第二次试用没那么典型，先说明：那一批活是修复测试和现场暴露的一批问题，bug 修复多过需求变更，原始代码的设计质量不高，硬件情况也复杂。

这一批里，AI 起草了修改方案和头一批提交，人工介入至少有四次：实施前两轮方案评审；实测戳破了 AI 设计的一个机制——日志证明某个状态保持是底层的偶然行为，不是设计语义，方案推翻重做；AI 为完整性设计的一套多帧缓存处理，被"量产项目最小修改"的原则回退了；最后模拟测试中又暴露了一个问题，再修一轮。

同样在这一批里，AI 自己验证时抓出了方案原文里一处写反的比较符号；它还在反馈文件里上报了一起自己造成的事故：生成提交脚本时把转义符写错，真实换行混进了首版提交，靠字节级比对才发现，随后修正。反馈文件是技能库里专门设计的机制，每次交付都要填，限半页——模板里的原话是，超了就没人维护。

## 踩坑与教训

维护线走通了，不代表 AI 可靠了。这条线踩过的坑，最后都变成了技能里的条款。

最常见的一类错误藏在假设里。技能规则中留着一条记录：曾经一次确认，七条假设里有两条和真实实现完全相反。AI 列假设的时候语气向来平静，对的和错的读起来一模一样，这就是清单必须逐条过人的原因——省掉这一步，错误直接流进代码。

第二类坑是逻辑自洽、但不物理成立。前面那次试用里被实测戳破的机制就是这样：代码层面读不出毛病，它依赖的行为恰好"看起来"存在。这类问题没有别的办法，只有实测能暴露。所以流程把实测放在必经路径上，AI 的结论不能直接过关。

还有一类算不上错误，是倾向：AI 喜欢做正确而完整的方案，维护场景要的却是最小修改——改动面在量产项目里就是风险面。这条后来写成了明确规则：不顺手修清单外的 bug，不做方案外的优化。附带还有一条更朴素的：AI 的交付物也要审计，审计要到字节级，"看起来对"和"确实对"之间，得靠工具来填。

## 为什么这次成了

回头对照第一次失败复盘出的两个根因，维护线几乎是逐条翻转过来的。

需求是真实的。变更维护每天都在发生，不存在为假想需求设计的问题——每条流程都是被一个真实变更逼出来的，哪一步多余，下一次试用就会硌脚。

范围也小了很多。只做变更维护一件事，不贪全流程，整个技能库七百行，不到上一个体系技能量的五分之一。规模小才改得动，回放验证一轮只要一天。

确认是前置的。人的精力没有花在通读 AI 的长文档上，花在两张清单上：假设和方案。第一次失败里那个交互带宽问题，答案是让人审得更少、更准，把审阅从全文缩到决策点。

如果有人问我现在怎么起步，我的答案比上一篇又具体了一点：从维护类工作切入，需求边界清晰、验证链短、见效快，最适合验证想法；把人工确认放在假设和方案这种决策点上，不要放在全文审阅上；每次交付留一页反馈，机制比热情可靠。

## 下一篇

维护线验证过的东西——两道闸、索引先行、反馈机制、最小修改——后来大都带回了新体系。带着这些回头重构最初失败的那个大体系，是下一篇的事。


这是《嵌入式 AI 落地手记》的第三篇。上一篇讲了新体系怎么失败的：目标贪多，模板膨胀，试用停在需求和设计两步。这篇讲之后的事——AI 第一次在真实项目里完整跑起来，不在新体系上，而在一个不起眼的地方：老项目维护。

03 · 新体系失败后，一个老项目维护需求让 AI 真正落了地

人工智能

开发工具

架构设计

老项目维护场景中，AI技能库以五步流程和两道人工确认闸实现高效变更管理，一周搭建、700行代码，经回放验证和两次真实试用，验证了假设前置和最小修改原则，形成可复用的维护方法论。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

03 · 新体系失败后，一个老项目维护需求让 AI 真正落了地-腾讯云开发者社区-腾讯云

03 · 新体系失败后，一个老项目维护需求让 AI 真正落了地

03 · 新体系失败后，一个老项目维护需求让 AI 真正落了地

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐