*——第一次失败：目标贪多的代价*

> 这是《嵌入式 AI 落地手记》的第二篇。上一篇讲了我为什么决定重构开发流程，结尾留了句话：第一次尝试失败了。这篇就讲这次失败——它怎么发生的，以及它留下了什么。

## 三个目标，一个都不想放

判断 AI 编程跨过可用门槛之后，我着手做的第一件事，是为新项目搭一套 AI 原生的开发体系。

体系的形式是我和 AI 来回讨论了很多次才逐渐定下来的：一个仓库模板，里面放文档模板和技能（skill），再配上文件服务器的目录模板，三者组合。文档模板负责告诉 AI"每个阶段要产出什么、写到什么程度"，技能负责告诉 AI"具体怎么干活、怎么检查"。

目标定了三个：合规、高质、高效。

合规排在最前面。当时我们预期要满足行业内的最高要求，所以体系的很大一部分是按这个标准设计的：需求要分类编号，文档之间要能双向追溯，每篇文档有自己的状态和修改记录。高质和高效字面上都好理解——质量不能降，效率要提上去。

现在回头看，这三个目标单独看都没错。放在一起，就是灾难的开始。

## 第一版模板有多重

六月底，第一版仓库模板建出来了。举几个例子，说明它有多"重"：

- 需求要分成七类，每类有独立的编号前缀，法规合规单设一章；
- 设计文档里有一张"接口索引与覆盖"表，用来做反向追溯，计划交给 AI 维护；
- 每篇文档开头挂着一组状态字段（草稿、已批准……），末尾强制带一张修改记录表，文档信息还要把项目元数据整段复制一遍；
- 配了七个检查类技能，覆盖各阶段的评审和质量检查。

注意最后一条：只有检查，没有生成。这套体系里 AI 的角色是守门员而不是前锋——它能挑毛病，但起步阶段的需求、设计文档，主要还得靠人带着它写。这个缺陷当时没有意识到，是后来才补上的。

## 在第一个真实项目上

七月，模板在第一个真实新项目上用起来了。具体该怎么用，我们心里都没底，各按各的理解摸索。

第一个问题出在输入上。客户的输入里有大量二进制原始文件，AI 读这些文件本身就吃掉大量上下文，真正开始干活之前，额度已经去了一半。我们赶紧补了一个步骤：先把二进制原始文件转成 Markdown，再进流程。

但这个转换规则只写了下限，没写上限——要求"不丢失信息"，没有要求"控制复杂度"。于是转换出来的文档把原始文件里的每个细节原样保留，需求文档顺着这个密度一路膨胀。

膨胀到什么程度？几个数字：需求阶段十二天改了八版，终版五百八十多行；设计文档两天突击出来，也是五百八十多行。内容上也是同一个走向：测试阶段才该做的验收项，提前写进了需求文档；接口协议的行为细节，整段整段出现在设计文档里；术语表把行业里最基础的缩写都挨个定义了一遍。这些写法单看都算不上错——问题不在写文档的人，在模板。它的倾向是"不要遗漏"，而不是控制复杂度，文档只是忠实地执行了这个倾向。

第二个问题是交互带宽。AI 生成一版内容要推理不短的时间；人拿到结果，阅读、理解、指出问题，很费劲；意见提给它，它理解和修改又要很久。需求阶段我们小会讨论过几次，实际用下来的反馈很一致：按这套文档和模板走，比自己写还费时间，一天的工作时间里和 AI 交互不了几轮。

第三个问题出在我原来的设想上。我计划的用法是：AI 出初版，后续由人手工编辑、修改、维护。实际执行发现这条路走不通——人手工改 AI 写的文档，效率低，改不完整，而且人不完全理解 AI 的写作模式和习惯，改动越多越容易和它原有的结构打架。

整个过程是在怀疑、讨论、调整中度过的。七月底，设计评审通过。从当天下午开始，后续的编码和测试就没再参考这套工作流——项目进度等不起了，我们按自己的方式把项目做完了。文档也再没有更新过，那批文档成了评审那一刻的快照，和代码从此各走各的。

第一套体系的试用，就此停在了需求和设计两步。

## 复盘：两个根因和一个机制

这次失败有两个根因。

**一是目标过载。** 合规、高质、高效，三个目标互相拉扯，最后全压在了文档模板上。模板要承载合规的追溯要求，要承载质量的检查点，又不能拖慢效率——结果是每一项目标都打了折扣，每一项的成本却都实实在在付了。

**二是为假想需求过度设计。** 合规那部分，是按当时预期要满足的最高要求设计的。后来业务定位调整，这类要求不再是硬约束——也就是说，体系里最重的那部分，服务的是一个最终没有出现的需求。软件开发里有条原则叫 YAGNI——"You Aren't Gonna Need It"，你不会需要它——意思是只实现当前真实需要的东西，不为假想的未来需求买单。这条原则一般用在代码上，这次我学到的是，体系设计也一样：流程和模板，同样不能为假想需求买单。

还要说清楚一点：把"合规"从目标里拿掉，不是因为 AI 原生的工作流做不了合规。计算机科学里有句老话：所有问题都可以通过增加一个间接层来解决——它还有后半句，"除了间接层太多的问题"。要求有多高，就需要复杂度和它相匹配的流程来承载，合规也一样，无非是把流程再加一层。只是业务上不再需要、技术上又还没有经验，"合规"才不再是当前的目标。哪天它重新成为硬约束，这套体系要做的也不是推翻重来，而是把那一层加回去。

两个根因之外，还有一个更具体的机制教训：给 AI 定的每条规则，都要同时想清楚下限和上限。"不丢失信息"是下限，没有上限，文档就会无限膨胀。这个教训后来直接改变了我们给 AI 写所有规则的方式。

公平地说，这次试用不是全输。反馈里有一条我很重视：虽然过程费劲，但需求阶段就把项目实现的细节想明白了——放在过去，这些漏洞往往要到设计甚至编码阶段才暴露。流程本身有问题，但"让 AI 深度参与需求"这件事，没有。

## 失败留下了什么

试用的反馈很快转化成了行动。需求文档发布的第二天，模板仓库开始了第一波精简：删掉那张反向追溯表——维护成本高、信息增量小；检查规则里"靠 AI 眼力排序""模糊词检查"这类不可重复的判断，改成工具化的检查。这批改动里能看到当时对 AI 能力边界的实战认知：哪些事 AI 做得比人稳，哪些事不能指望它。

更长远的是两样东西。

一样是"AI 起草、人拍板"的分工。手工编辑路线失败之后，我们意识到人和 AI 的协作界面不在"编辑"上，而在"决策"上。这个分工后来贯穿了整个体系——上一篇说"每一步保留人工审核"，它真正的来历就是这次失败。

另一样更意外：那个失败项目留下的代码，后来被整理提取，成了我们知识库的第一批素材。第一次失败留下的资产，成了后来重构的地基。

这次失败之后，再有同行问我怎么起步，我的回答就几句话：先把原始文件转成 AI 读着省力的形式，别把上下文浪费在读二进制上；给 AI 的每条规则，下限和上限都写清楚；目标一次只扛一个，扛不动的先砍掉；人和 AI 的分工放在"决策"上，别放在"编辑"上。

## 下一篇

新项目这条线停下来反思的时候，另一个更朴素的需求找上门来：老项目的日常维护。没有宏大目标，没有体系设计，就是手头几件具体的活。

意外的是，AI 真正落地，恰恰是从这里开始的。


这是《嵌入式 AI 落地手记》的第二篇。上一篇讲了我为什么决定重构开发流程，结尾留了句话：第一次尝试失败了。这篇就讲这次失败——它怎么发生的，以及它留下了什么。

02 合规、高质、高效我全都要：AI 开发体系一上线就败了

人工智能

开发工具

职业发展

首次AI原生开发体系试用失败：因目标过载（合规、高质、高效互相拉扯）及为假想需求过度设计，导致文档膨胀、交互低效。复盘总结出规则需设下限与上限、目标聚焦单一、人机分工在决策而非编辑等关键教训，为后续重构奠定基础。

软件开发

服务器

AI编程

Markdown

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

02 合规、高质、高效我全都要：AI 开发体系一上线就败了-腾讯云开发者社区-腾讯云

02 合规、高质、高效我全都要：AI 开发体系一上线就败了

02 合规、高质、高效我全都要：AI 开发体系一上线就败了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐