AI研发流程初步实践（六）：持续改进与知识沉淀

发表于 更新于 分类于 ，
如何与AI建立有效协作、从AI输出中学习、建立知识库、三层评估输出质量、持续优化协作流程、避免过度依赖AI、方案对比

前五篇文章分别讨论了流程、质量、文档、长期迭代维护、边界问题。本篇是Track 2的收束——回到方法论本身。AI辅助开发不是一项静态技能，它随模型升级、工具演进、项目累积在持续变化。今天用得顺的工作流，半年后可能就因为模型行为改变而过时。这篇文章讨论的不是”一套规则”，而是一套让规则持续进化的方法论：如何与AI建立有效协作、如何从AI输出中学习、如何沉淀知识、如何评估输出、如何持续优化流程，以及如何避免过度依赖。

一、概念：方法论本身也是一个持续演进的系统

如果把前五篇文章比作一套”招式”，那本篇讲的就是”心法”——招式会过时，心法不会。

AI辅助开发的独特之处在于：工具本身在快速进化，你的协作方式必须同步进化。去年好用的提示词策略，今年模型升级后可能不再必要；去年AI不擅长的任务，今年可能已经处理得很好。这意味着你不能把”AI辅助开发方法论”当做一套固定的规则集，而要看成一个活的系统——它需要被持续观察、调整、优化。

这个系统的核心循环是：实践 → 反思 → 沉淀 → 优化 → 再实践。下图展示了这个持续改进闭环的完整结构——从协作到学习、从知识沉淀到评估再到优化，形成自我演进的循环：

持续改进闭环

你每次与AI协作都是一次实践，协作后反思哪些做得好、哪些不好，把经验沉淀到知识库（project_memory、design-notes），然后调整下一轮的协作方式。

这个循环不是可选的，而是AI辅助开发的必修课。因为AI不像传统工具——你用一个编辑器十年，它的行为模式基本不变。AI每隔几个月就可能升级一次模型，行为模式可能大幅变化。你的协作方法论如果不跟着调整，就会出现”以前这么用没问题，现在怎么变了”的困惑。

二、通用设计方案：建立有效协作的四层体系

2.1如何与AI建立有效协作

协作不是”给AI一个任务，等它交付”。是双向的——你影响AI的行为，AI的输出反过来影响你的判断。建立有效协作有三个关键要素：

要素一：提示词要具体。

“写一个用户登录功能”是模糊提示。AI收到这个提示后，会默认脑补一套”完整”方案——可能包含OAuth集成、记住我功能、短信验证码、二次验证——因为你没说不做这些。它给出的方案”看起来专业”但远远超出了你的实际需求。

“用bcrypt哈希密码、JWT有效期24小时、失败5次锁定15分钟、不引入新依赖”是具体提示。AI的输出被明确约束，不会跑偏。

具体的本质是把你的判断前置——先想清楚要什么，再让AI做，而不是让AI猜你要什么。模糊提示等于把决策权交给了AI，而AI在决策时倾向”做最完整的版本”。

要素二：上下文要充分。

AI没有项目记忆，每次会话靠你给的上下文工作。上下文越充分，AI输出越贴合项目。上下文应包括：

  • spec：当前版本的设计意图，告诉AI”我们要做什么”
  • design-notes：跨版本的长期约束和决策历史，告诉AI”我们以前做过什么决定、为什么”
  • project_memory：项目的硬约束和原则，告诉AI”什么能做、什么不能做”
  • 当前subtask描述：当前要做的事情的焦点，告诉AI”你现在只需要关心这个”

上下文给得越少，AI越倾向”通用最佳实践”——而”通用的最佳实践”通常不适合你的具体项目。这对组合不是”偶尔给一下”，而是每次任务开始前必须准备好的。

要素三：约束规则要工具化。

提示词里写”请用TDD”是建议，AI可以选择性遵守——它可能口头上答应”我会用TDD”，但实际操作时跳过测试直接写实现。用skill强制TDD是约束，AI必须走完”写测试→看RED→写实现→看GREEN”的完整流程才能继续。

区分”建议”和”约束”很简单：建议AI可以忽略，约束AI无法跳过。能工具化的约束不要停留在提示词。因为提示词是”告诉AI怎么做”，工具是”确保AI必须这么做”。

具体哪些约束值得工具化：测试规范（TDD强制）、流程规范（plan→实现→review的顺序）、分支策略（工作树隔离）、版本收尾（封仓checklist）。这些是高频AI最容易”偷懒”或”跑偏”的环节，工具化之后能显著提升协作质量。

2.2如何从AI输出中学习

AI输出不只是”拿来用的代码”，更是一份学习材料。每一段AI写的代码、每一份AI写的设计文档，都藏着可学习的东西——前提是你愿意拆解。

不只接受结果，理解原理。

AI给你一段用 Promise.allSettled 处理并发请求的代码，不能只复制粘贴。你要问：为什么用 allSettled 而不是 all？allSettled 和 all 的语义区别是什么？什么场景该用哪个？如果一个失败不影响其他请求的处理，allSettled 就比 all 合适；如果任何一个失败都应该让整个操作失败，那 all 才是正确的选择。

理解了原理，下次同类问题你自己能判断。不理解原理，下次AI给错了你也看不出来——AI经常会在该用 all 的地方用 allSettled，或者反过来，因为它在训练数据里见过两种用法但没有自己”理解”对错的边界。

对比AI的多次输出。

同一个问题让AI在不同时间、不同上下文下回答，对比差异。差异点通常是”可选方案”——比如一次AI用了callback模式，另一次用了Promise模式。理解为什么两种方案都可选、各自的优缺点是什么、在自己的场景下应该选哪个，这种对比能拓宽你的技术视野。

AI一次给的答案是”一个解”，多次给的答案对比是”解空间”。看到”解空间”才真正理解问题的上下文。

从AI的错误中学习。

AI写错的代码尤其值得研究。错在哪？为什么会这么错？这个错误暴露了AI对哪个概念的误解？研究错误比研究正确答案收获更大——正确答案看起来理所当然，你扫一眼就过了；错误暴露了思维的盲区和容易混淆的边界。

比如AI在写SQL查询时忘记了加 WHERE 条件而导致全表更新——这个错误本身不复杂，但它暴露了”AI在构建SQL语句时可能丢失关键约束”的问题。你学到了：以后让AI写SQL时必须显式要求”逐条检查WHERE条件”。

警惕”看起来对”的代码。

AI写的代码往往命名合理、结构整齐、注释齐全，看起来很专业。但”看起来对”不等于”对”。学习时要验证——跑测试、查文档、读源码确认、问自己”这段代码在边界情况下会怎样”。不验证地接受，你学到的是”AI的自信”，而不是”技术的正确”。

“看起来对”是最危险的。如果是明显错误的代码，你会立刻质疑；但”看起来对”的代码让你放松警惕，把错误当正确接受。

2.3如何建立知识库

知识库是项目累积的”关于如何协作的知识”资产。分两层：

memory（会话级记忆）：当前会话的工作记忆。AI在会话中学到的”这个项目的约定””你的偏好””当前任务焦点”，存在会话的working memory里。会话结束就消失，是短期的。memory的作用是让AI在单次会话中有连续性——不会前面说完后面忘。

project_memory（项目级知识库）：跨会话的长期记忆。硬约束、教训、原则、架构地图，写在project_memory里，每次会话注入system prompt。这是长期的、累积的、每次会话都可用。

project_memory该写什么、不该写什么，需要区分清楚：

该写的内容：

  • 硬约束：项目里不能违反的规则。例如”core层不能import access层””API key只能从环境变量读取””测试不能依赖外部网络”。
  • 教训：踩过的坑及对应的约束。例如”AI曾经跳过测试直接写实现导致上线hotfix，从此TDD设为红线，必须用skill强制”。
  • 原则：项目遵循的设计原则。例如”YAGNI””加法而不减法””错误不持久化”。
  • 当前版本焦点：本版本做什么、不做什么，避免AI跑偏到未来版本的功能。

不该写的内容：

  • 具体代码：代码在仓库里，不用memory重复。project_memory是规则，不是代码库。
  • 临时决策：临时决策放spec而不是memory。下个版本spec会覆盖它，留在memory里会过时。
  • 过期信息：过期的约束比没有约束更糟——它会让AI遵守已经不成立的规则。project_memory需要定期清理，下个版本不再适用的约束要及时移除。

project_memory要精简。它每次会话都会注入system prompt，太长浪费token、稀释信号。几百到一千字最合适，只覆盖最关键的约束与原则。详细内容放spec和design-notes，project_memory是”宪法”不是”法典”。

知识库的维护是持续过程。每个版本封仓后回顾：本版本踩了什么新坑？project_memory该加什么约束？哪些老约束已经过时该删？知识库不更新会变成”历史包袱”——AI读着过时的约束做决策，比没有约束更糟。

2.4如何评估AI输出质量

AI输出不能”看起来对就接受”。评估质量的三层递进标准：

第一层：测试通过。 最基础的条件。测试不通过，输出一定有问题。但测试通过不等于输出没问题——测试可能覆盖不全、断言太弱、mock掉了真实逻辑。通过是第一道门槛，不是最后的标准。

第二层：review代码。 人读一遍AI写的代码，问几个问题：这段代码做了什么？为什么这么做？有没有更简单的方式？边界情况处理了吗？有没有引入未要求的依赖或抽象？有没有安全风险？

Review不是不信任AI，是把AI当作”很会写但偶尔跑偏的同事”。它的产出值得审，审的过程也是你学习的过程——你会在review中发现AI的常见模式，这些模式会成为你下次写提示词时的参考。

第三层：对比预期。 AI的输出与你的预期一致吗？如果一致，是AI真的理解了你的需求，还是它恰好给了个”看起来像”的答案？如果不一致，是AI错了，还是你的预期本身需要调整？

这一层最难。它要求你区分”AI的输出符合预期”和”AI的输出正确”——预期本身可能是错的。比如你让AI用某种模式实现功能，AI用了另一种模式但更简洁——这时候你该坚持”符合预期”还是接受”更好的方案”？

评估质量要避免两个极端：一是全盘接受（”AI写的肯定对”），二是全盘怀疑（”AI写的肯定有问题”）。前者放弃判断，后者浪费AI的价值。正确的是信任但验证——AI在它擅长的领域（模式化代码、测试生成）可以较高信任，在它不擅长的领域（架构、安全）必须严格验证。

2.5如何持续优化协作流程

协作流程不是一次设计完成的，需要持续优化。优化循环包括四步：

第一步：复盘。 每个版本封仓后，回顾本版本的协作情况。哪些subtask走得顺？哪些反复熔断？哪些AI行为让你意外？复盘要诚实——“这次AI表现很好”如果是真的，要找出好在哪（是spec写得好？是约束配置到位？）；”这次很糟”要找出糟在哪（是需求模糊？是约束不够？）。

复盘不需要长篇大论，几个关键问题就够了：

  • 这个版本AI在什么场景下表现最好？什么场景下最差？
  • 有没有出现新的踩坑模式，还没有被约束覆盖？
  • project_memory需要加什么或改什么？

第二步：调整约束。 复盘发现的模式转化为具体约束。比如发现”AI总是引入不必要的抽象”，就在project_memory加一条”YAGNI是硬约束，引入抽象必须论证必要性”。发现”AI经常在数据库操作里忘记加事务”，就加一条”数据库写操作必须显式说明事务边界”。

约束调整是迭代的——加了约束观察效果，效果不好再调整。一次加太多约束会导致AI束手束脚、输出质量下降。每个版本调整一两个约束点，给调整时间生效。

第三步：迭代工作流。 工作流本身也要迭代。比如发现”plan阶段花太多时间”，可以调整plan的颗粒度——从”每个文件都写详细plan”变成”只写模块级别的plan，实现细节让AI在subtask里自己拆解”。发现”subtask隔离性不够”，可以调整拆分方式。

工作流不是教条，是工具——工具要服务于效果。如果某个流程步骤没有带来价值（或者带来的价值小于消耗的成本），就应该调整或删除。

第四步：记录调整。 每次流程调整都要记录在design-notes里。调整了什么、为什么调整、效果如何。不记录的话，半年后你忘了为什么这么调，下次又会调回去踩同样的坑。

记录时写清楚三件事：原来的做法、遇到的问题、新的做法及理由。这看起来是额外工作，但长期来看是”防止自己反复踩同一个坑”的保障。

优化要避免”过度优化”。工作流调整太频繁，你跟不上节奏，每次都在适应新流程反而低效。一个经验法则：每个版本最多调整一两个流程点，给调整时间生效，观察累积效果。

2.6如何避免过度依赖AI

AI辅助开发的隐性风险是过度依赖。症状很明显，但当事者很难自察：

  • 不写AI不会写的代码了。遇到复杂逻辑，第一反应是”让AI写”，而不是”我自己先想清楚”。久而久之，写复杂逻辑的能力会退化。
  • 不review AI代码了。”AI写的应该对”成了默认假设。你不再质疑AI的输出，即使觉得”这段代码有点怪”也会告诉自己”AI应该比我想得周全”。
  • 失去批判性思维。AI给的方案不再质疑，直接采纳。以前你会想”这个方案有什么优缺点”，现在你只想”这个方案能跑吗”。
  • 核心决策外包。架构方向、技术选型、工具选择都让AI建议，自己只做”批准”。但批准不是决策——你只是确认了AI的想法，没有形成自己的判断。

过度依赖的代价是能力退化。长期让AI写复杂逻辑，你自己写复杂逻辑的能力会萎缩；长期不review，你读代码的能力会萎缩；长期不质疑，你的技术判断力会萎缩。等某天AI不可用或给错答案，你发现自己已经无法独立判断。

对策是保持核心决策自主：

  • 架构方向自己定，AI只提案、不决策。你决定”用什么框架””怎么分层””引入什么模式”，AI负责写实现代码。
  • 关键算法自己理解，不只接受AI的实现。即使最后用了AI写的代码，也要读懂了再接受。
  • 安全相关代码自己审，不依赖AI自检。安全逻辑的错误不会立即暴露，但暴露时往往已经造成了损失。
  • 复杂逻辑偶尔自己写，保持手感。不需要所有代码都自己写，但定期让自己写一些”有挑战”的代码，保持能力的活跃度。
  • 持续学习，AI是加速器不是替代品。新技术、新范式、新工具依然需要你主动学习——AI可以做摘要和总结，但深入理解还得靠你自己。

AI是放大器——放大你的能力，也放大你的盲点。能力强的人用AI如虎添翼，能力弱的人用AI加速犯错。保持自己的能力，AI才是增益；放弃自己的能力，AI就是依赖陷阱。

三、市面其他方案对比

面对”如何持续改进AI协作”这个问题，不同的团队和个人有不同的处理方式。大致有三种典型路线。

3.1方案A：随用随学，不系统化

这种方案的核心态度是”用就完了”。开发者不刻意记录经验、不整理知识库、不回顾优化流程。每次会话都是”从零开始”——提示词现写、约束现想、流程现定。遇到问题了，下次注意一下，但不会花时间把经验沉淀成可复用的资产。

适用场景： 偶尔使用AI的开发者、一次性项目、对AI输出质量要求不高的场景。

优势： 最灵活，没有额外负担。对于”每周用一两次AI”的开发者来说，确实不需要建立系统化的方法论。

代价： 没有累积效应。每次会话的效率完全取决于当次的发挥——状态好时协作顺畅，状态差时各种踩坑。经验存在脑子里，换个项目、换个时间、换个AI工具，一切需要重新摸索。对于频繁使用AI的开发者来说，方案A的效率天花板非常低——你会在同一个坑里反复摔跤。

3.2方案B：个人经验总结

这种方案比方案A进了一步：开发者会做个人经验总结。可能是记在心里，也可能写在个人笔记里。发现有好的提示词模板就收藏，发现踩了坑就记下来下次注意。

适用场景： 个人重度AI用户、有自省习惯的开发者。

优势： 经验得到了一定程度的沉淀。个人笔记中的知识可以复用到下一个项目。随着时间累积，开发者的AI协作能力会提升——因为他记住了以前的教训。

代价： 经验是个人化的，无法跨项目、跨团队传承。如果换了开发者（或者项目交接给其他人），”经验存在个人笔记里”等于不存在。而且个人笔记通常是非结构化的——今天记了明天就找不到，回头翻笔记要花很多时间。

在AI辅助开发的场景下，方案B还有一个致命问题：AI读不到你的个人笔记。你的个人经验只能优化你自己的行为，不能优化AI的行为。让AI表现得更好需要把经验沉淀到AI能读取的地方（project_memory、workflow文档等）。

3.3方案C：系统化沉淀方法论

这是前面”通用设计方案”描述的方法论。核心特征：

  • 知识库分层：memory（会话级）和project_memory（项目级）区分。短期记忆在会话中有效，长期记忆跨会话累积。
  • 评估体系化：三层评估标准——测试通过 → review代码 → 对比预期。不是”感觉对就行”，而是有递进的验证步骤。
  • 复盘流程化：每个版本结束后正式复盘，复盘结果写入design-notes和project_memory，作为下一版本的输入。
  • 约束工具化：沉淀下来的经验不是”记在笔记里”而是”变成约束写进工作流”。约束不是提醒自己”下次注意”，而是强制AI按规范执行。
  • 闭环迭代：实践→反思→沉淀→优化→再实践，形成持续改进的闭环。最近一次实践改了之后，下一次实践会评估改的效果，再改再实践。

适用场景： 重度AI用户、长期迭代项目、多人协作AI辅助开发。

优势： 经验被系统化地沉淀和传递。AI能读到project_memory中的约束，人类能读到design-notes中的决策历史。项目层面的协作方法论不会因为”人走了”或”项目换手”而丢失。持续改进的闭环保证了方法论不会僵化，而是随AI能力升级同步进化。

代价： 前期投入较高。建立project_memory、定义评估标准、设置复盘流程都需要时间。在最初一两个版本，这些投入看起来是”额外工作”——但第三五个版本之后，累积效应开始显现，前期的投入开始产生回报。

3.4设计哲学对比

维度 方案A（随用随学） 方案B（个人总结） 方案C（系统化沉淀）
核心态度 用就完了 经验在脑子里 知识库 + 闭环迭代
知识沉淀 无 个人笔记 project_memory + design-notes
AI能否读取 不能 不能 能（约束注入）
复盘机制 无 偶尔回想 版本结束后正式复盘
评估标准 感觉 个人判断 三层递进（测试→review→对比）
约束形式 无 “我下次注意” 工具化流程强制
适用频率 偶尔使用 频繁使用 持续日常使用
可传承性 无 个人级 项目级

三条路线的本质差异在于”经验是否被系统化”——方案A不做经验沉淀，方案B做个人级沉淀，方案C做项目级、工具级的系统化沉淀。

四、aptbot的设计特点

aptbot选择方案C作为方法论基础。原因很直接：aptbot是一个学习型项目，它不仅要自己用好AI，还要作为示例展示”如何系统化地改进AI协作”。

具体实践中，aptbot建立了完整的持续改进闭环：

知识库体系。 aptbot区分了会话级memory和项目级project_memory。memory用于当前会话的工作记忆——告诉AI”这个会话里我们刚做了什么、正在做什么”。project_memory是跨会话的长期约束——每次新会话自动注入，让AI从第一轮就知道项目的规则。两者互补，前者保证会话连续性，后者保证跨会话一致性。

三层评估内嵌。 aptbot的工作流中嵌入了评估机制：测试通过是最低门槛（不通过不能提交），然后是review环节（人工或AI review代码质量），最后是预期对比（在UAT阶段对照spec核验输出是否匹配设计意图）。这三层不是可选的，而是流程中强制执行的步骤。

复盘作为版本正式活动。 每个版本封仓后的冷却期，复盘是标准流程之一。复盘输出写入design-notes和project_memory——新的教训加进约束，过时的约束被清理。复盘不是”有空就做”，是版本迭代的一部分，和写代码一样正式。

约束工具化。 aptbot的经验不止于文档提醒，而是通过skill（预配置的工作流模板）强制执行的。TDD约束、熔断机制、plan不含代码规则——这些不是”记在project_memory里的建议”，而是AI必须遵守的流程。工具化的约束让AI没有”选择忽略”的路径。

持续迭代工作流。 aptbot的工作流本身也在版本化演进。每个版本可能调整一两个流程点——调整subtask拆分的颗粒度、优化spec模板的结构、细化UAT核验的清单。工作流迭代也记录在design-notes里，保证每次调整都有据可查、每个调整都有明确理由。

aptbot的设计传递了一个核心理念：方法论不是死的，是活的。你不需要在第一天就拥有完美的协作流程，但你需要从第一天就开始迭代它。

五、发展方向

AI辅助开发的方法论在持续演进。几个值得关注的趋势：

更智能的上下文管理。 当前project_memory是”全注入”模式——每次会话注入全部约束。未来可能根据当前subtask的上下文，动态选择注入哪些约束——比如涉及安全时注入安全约束，涉及测试时注入TDD约束。这能减少token浪费，提高信号密度。

AI辅助的复盘。 复盘目前依赖开发者手动回顾。未来AI可以在版本封仓时自动生成”版本协作报告”——列出本版本中熔断的次数和原因、AI重试的频繁度、约束被触发的统计。开发者基于报告做复盘会更高效。

跨项目知识迁移。 当前的project_memory是项目隔离的——一个项目的经验不会自动迁移到另一个项目。未来可能出现知识迁移机制，让一个项目中沉淀的AI协作经验（提示词模式、约束规则、文档模板）能复用到一个新项目中。

团队级知识共享。 多人协作用AI时，不同成员的AI协作经验如何共享？一个人踩了一个坑，如何让整个团队（以及团队的AI）都避免这个坑？团队级的project_memory和协作复盘机制会变得越来越重要。

aptbot会在后续版本逐步探索这些方向。核心原则不变：持续改进的关键不是工具，而是习惯——复盘的习惯、记录的习惯、评估的习惯。工具可以辅助习惯，但习惯的建立必须靠你自己。

小结

本篇是Track 2的收束，也是整个方法论的”元视角”——不再讨论具体的协作技巧，而是讨论如何让协作技巧本身持续进化。

核心要点：

  1. 有效协作需要三个要素：具体提示词、充分上下文、工具化约束。三者缺一不可。
  2. 从AI中学习不仅要接受结果，更要理解原理、对比多次输出、研究AI的错误、警惕”看起来对”的代码。
  3. 知识库应该分层——会话级memory保证连续性，项目级project_memory保证一致性。两者配合，AI才能稳定输出。
  4. 评估质量要三层递进——测试通过 → review代码 → 对比预期。每一步都不能跳过。
  5. 优化流程要闭环——复盘→调整约束→迭代工作流→记录调整。每个版本迭代一两个点，持续累积。
  6. 避免过度依赖——保持核心决策自主、保持阅读代码的习惯、保持”不用AI也能做”的能力。

三条路线中，方案C（系统化沉淀方法论）是持续使用AI的必然选择。它不是最轻松的（前期需要投入），但它保证你的AI协作能力不会停滞——你会在每次迭代中变得更好。

Track 2的五篇文章（流程、质量、文档、长期迭代、边界、持续改进）构成了AI辅助开发的完整方法论。回到Track 1，看一个具体的agent项目如何在这些方法论下从MVP起步、走向演进路线。