1. 为什么需要搭建自己的 AI 编程过程框架
1.1 从“能用”到“好用”的分水岭
过去一年多，我陆续用 AI 辅助完成了十几个大小项目，从脚本工具到完整的后端服务都有。最开始我的用法很粗暴：打开对话框，把需求描述一遍，复制代码，粘贴到编辑器，跑一下，报错了再贴回去让它改。这个循环在简单任务上勉强能用，但只要项目稍微复杂一点，问题就集中爆发了——上下文丢失、风格不统一、改一处崩三处、同一个 bug 反复出现。
后来我意识到，问题不在于模型不够强，而在于我根本没有一套属于自己的“过程框架”。所谓 AI 编程过程框架，说白了就是把“人怎么想、AI 怎么接、代码怎么落地、结果怎么验证”这一整条链路固化下来，形成一套可重复、可迭代、可追溯的工作流。它不是某个具体工具，也不是某个提示词模板，而是一套把需求拆解、上下文管理、代码生成、验证回滚、知识沉淀串起来的操作系统。
这套框架解决的核心问题是：让 AI 的输出从“一次性灵感”变成“可积累的工程资产”。适合谁来参考？我认为三类人收益最大。第一类是独立开发者，一个人要顶一个团队，效率就是生命线；第二类是小团队里的技术骨干，需要把 AI 能力复制给同事，形成团队规范；第三类是有一定编程基础、想系统化提升 AI 协作效率的进阶学习者。如果你还在“复制粘贴碰运气”的阶段，那这套框架值得你花时间搭起来。
1.2 框架的三个层次：提示、流程、资产
我把自己这套框架拆成三个层次来理解，这样搭建的时候不会乱。
最底层是提示层，解决的是“怎么跟 AI 说清楚”。这里面包括角色设定、任务描述、约束条件、输出格式。很多人卡在这一层，以为提示词写得越花哨越好，其实核心就一句话：把 AI 当成一个能力很强但完全不了解你项目背景的新同事，你需要把背景、目标、边界一次性交代清楚。
中间层是流程层，解决的是“按什么顺序做”。一个功能从想法到上线，中间要经过需求澄清、方案设计、接口定义、代码实现、测试验证、文档更新这几个环节。每个环节 AI 能承担多少、人要把关什么，需要提前定好。流程层的价值在于，它把“随机对话”变成了“流水线作业”，每一步的输入输出都是明确的。
最上层是资产层，解决的是“做完之后留下什么”。包括项目上下文文件、提示词库、代码片段库、踩坑记录、决策日志。这一层最容易被忽略，但恰恰是拉开差距的地方。没有资产层，你每次都在从零开始；有了资产层，你的 AI 协作效率会随着项目推进越来越高，而不是原地打转。
提示：三层不是割裂的，资产层的沉淀会反过来优化提示层和流程层。搭建顺序建议从流程层入手，先跑通一条最小闭环，再逐步补提示和资产。
2. 核心组件拆解与选型思路
2.1 上下文管理：让 AI 记住你的项目
上下文管理是整个框架的地基。我踩过最大的坑就是：每次开新对话，AI 都像失忆一样，之前定的命名规范、目录结构、技术选型全忘了。解决办法不是把整个项目塞进对话，那样既贵又乱，而是建立一套分层上下文机制。
我的做法是维护三个文件。第一个是项目宪法，放在项目根目录，内容包括技术栈版本、目录结构约定、命名规范、错误处理风格、日志规范、依赖管理原则。这个文件控制在 500 字以内，每次开新对话第一件事就是把它贴进去。第二个是当前任务卡，只描述本次要做的功能，包括目标、输入输出、边界条件、验收标准。第三个是变更日志，记录每次 AI 生成代码后做了哪些修改、为什么改、遗留了什么问题。
这三个文件的分工很明确：项目宪法管“长期不变的原则”，任务卡管“本次要做什么”，变更日志管“做完之后发生了什么”。实测下来，有了这三层，AI 输出的代码风格一致性提升非常明显，返工率至少降了一半。
选型上，我试过把上下文写进系统提示、写进对话开头、写进代码注释，最后发现独立文件加手动粘贴最可控。系统提示容易被平台限制，代码注释会污染源码，只有独立文件既干净又灵活。如果你用的是支持项目级上下文的工具，那就把项目宪法放进项目配置里，任务卡和变更日志还是手动管理，这样颗粒度最合适。
2.2 提示词工程：从模板到策略
提示词这块，我走过两个极端。一开始追求“万能模板”，结果发现不同任务用同一套模板效果很差；后来干脆不用模板，每次自由发挥，结果质量忽高忽低。最后的结论是：模板要有，但必须是分场景的，而且模板里要留出策略空间。
我目前维护四类提示词模板。第一类是需求澄清模板，用在动手之前，让 AI 反问我问题，把模糊需求逼清楚。第二类是方案设计模板，要求 AI 给出至少两种实现路径，并对比优劣。第三类是代码实现模板，明确要求输出格式、注释密度、错误处理方式。第四类是代码审查模板，让 AI 以审查者视角挑毛病，而不是继续写代码。
每类模板里我都会留一个“策略槽位”，比如代码实现模板里会写“优先考虑可读性还是性能，根据任务卡里的标注决定”。这样模板就不是死板的填空，而是带决策逻辑的框架。另外我强烈建议给每个模板标注适用场景和反例，比如“需求澄清模板不适用于紧急 bug 修复，那种情况直接用代码审查模板”。
2.3 版本控制与回滚：AI 代码的安全网
AI 生成的代码有个特点：看起来对，跑起来不一定对；改一处，可能悄悄影响另一处。所以版本控制和回滚机制必须前置，不能等出事了再补。
我的做法是：每次让 AI 生成代码之前，先提交一次当前状态，commit message 写清楚“AI 生成前基线”。AI 输出后，我先在独立分支上应用，跑通测试再合并。如果 AI 一次性生成了多个文件，我会拆成多个 commit，每个 commit 对应一个逻辑单元，这样出问题能精准回滚。
还有一个细节：AI 经常会在无关的地方做“顺手优化”，比如改了个变量名、调整了缩进。这些改动单独看没问题，但混在功能提交里会干扰 review。我的处理方式是，在提示词里明确写“只修改与任务直接相关的代码，不要做额外重构”，如果它还是改了，我就在提交前手动还原无关改动。
注意：不要依赖 AI 工具自带的“撤销”功能作为唯一回滚手段。对话历史可能丢失，工具可能换，只有 Git 提交记录是真正属于你的安全网。
2.4 验证闭环：怎么判断 AI 干得对不对
验证环节是很多人忽略的。AI 说“已完成”，不代表真的完成了。我建立了一套三层验证机制。
第一层是静态验证，包括语法检查、类型检查、lint。这些能自动跑的绝不靠肉眼。第二层是动态验证，针对本次改动写最小测试用例，跑通才算过。第三层是人工抽检，我会随机挑几个 AI 生成的函数，逐行读一遍，重点看边界条件、错误处理、资源释放。这三层里，第一层和第二层尽量自动化，第三层必须人工，因为 AI 最擅长在“看起来合理”的地方埋雷。
验证不通过怎么办？我的原则是：小问题让 AI 改，大问题自己改。如果只是变量名不对、少了个判空，直接让 AI 修；如果是架构层面的偏差，比如它选了个不合适的库，那就自己动手，因为让 AI 在错误方向上继续改，只会越改越乱。
3. 从零搭建框架的完整实操流程
3.1 第一步：定义你的项目宪法
项目宪法是整个框架的起点。我建议你拿一个真实项目来练手，不要空想。打开你的项目根目录，新建一个PROJECT_CONSTITUTION.md，然后按下面几个维度来写。
技术栈部分，写清楚语言版本、框架版本、包管理器、构建工具。比如“Python 3.11，FastAPI 0.104，Poetry 管理依赖，Ruff 做 lint”。目录结构部分，用树形图列出主要目录和职责，比如src/api放路由，src/core放业务逻辑，tests放测试。命名规范部分，写清楚文件命名、类命名、函数命名、变量命名的规则，比如“模块名用小写下划线，类名用大驼峰，常量全大写下划线”。
错误处理部分，写清楚异常怎么抛、怎么捕获、怎么记录日志。比如“业务异常统一继承 BaseError，日志用结构化 JSON，禁止 print”。依赖管理部分，写清楚什么情况可以加新依赖、什么情况必须自己实现。比如“能用标准库就不加第三方，新增依赖必须说明理由和替代方案”。
这个文件不要一次写完，先写你最有把握的部分，然后在实际协作中逐步补充。我自己的项目宪法改了七八版才稳定下来。关键是让它保持简短，超过 800 字就说明你写太细了，细到应该放进代码规范文档而不是宪法里。
3.2 第二步：建立任务卡与变更日志机制
任务卡是每次和 AI 协作的入口。我的任务卡模板包含五个字段：任务名称、背景说明、输入、输出、验收标准。背景说明写为什么要做这个任务，输入写依赖哪些现有代码或数据，输出写期望的文件或函数，验收标准写怎么算完成。
举个例子，任务名称是“用户登录接口”，背景是“现有认证模块缺少登录入口”，输入是“用户表结构、密码哈希工具”，输出是“POST /login 路由及对应 service 函数”，验收标准是“正确密码返回 token，错误密码返回 401，连续失败 5 次锁定 10 分钟”。你看，这样写完之后，AI 基本不会跑偏。
变更日志我放在CHANGELOG_AI.md，每次 AI 协作结束后追加一条，格式是：日期、任务卡编号、AI 生成的文件列表、人工修改点、遗留问题。这个日志看起来麻烦，但当你三个月后回头看某个功能为什么这么写时，它就是唯一的线索。而且它还能帮你发现 AI 的常见错误模式，比如“它总是忘记处理空列表”，下次就能提前在提示词里预防。
3.3 第三步：配置你的提示词库
提示词库不需要很复杂，我建议用一个 Markdown 文件管理，按场景分节。每节包含模板正文、适用场景、反例、使用心得。
需求澄清模板的正文大概是：“我是项目负责人，现在有一个模糊需求：[描述]。请你以资深工程师身份，向我提出不超过 8 个关键问题，帮助澄清需求边界。不要给方案，只提问。”这个模板我用了很多次，效果很好，因为 AI 提问往往能戳中我没想到的盲区。
方案设计模板的正文是：“基于以下任务卡：[粘贴任务卡]。请给出两种实现方案，分别说明核心思路、涉及文件、潜在风险、工作量估计。最后给出你的推荐及理由。”这个模板的关键是强制它给两个方案，避免它直接跳到实现。
代码实现模板的正文是：“基于以下任务卡和选定方案：[粘贴]。请生成代码。要求：只修改相关文件，保持现有风格，每个函数加简短注释，错误处理遵循项目宪法。输出格式为文件路径加代码块。”这个模板里“只修改相关文件”和“保持现有风格”是我踩坑后加上的，非常关键。
代码审查模板的正文是：“请以严格代码审查者身份，审查以下代码：[粘贴]。重点检查边界条件、错误处理、资源释放、命名一致性。按严重程度分级列出问题，不要直接改代码。”这个模板用在提交之前，能拦下不少低级错误。
3.4 第四步：跑通一个最小闭环
框架搭好后，不要急着上大项目，先拿一个小功能跑通全流程。我建议选一个“增删改查”里的“查”功能，因为逻辑简单、边界清晰、容易验证。
具体步骤是这样的。先写任务卡，明确要查什么、输入什么、输出什么。然后用需求澄清模板让 AI 提问，根据它的提问补充任务卡。接着用方案设计模板让它给两个方案，你选一个。然后用代码实现模板生成代码，在独立分支上应用。跑静态检查和测试，不通过就回到代码实现环节。通过后人工抽检，没问题就合并，更新变更日志。
这个闭环跑一遍大概半小时，但跑通之后你就有了一个可复制的模板。后面做复杂功能，只是在这个闭环上增加环节，而不是重新发明流程。我第一次跑通这个闭环时，最大的感受是“原来 AI 协作可以这么稳”，因为每一步都有明确的输入输出和检查点，不再靠运气。
3.5 第五步：迭代与沉淀
框架不是一次搭好的，我自己的框架迭代了大概两个月才稳定。迭代的驱动力来自每次协作后的复盘。我会问自己三个问题：这次哪个环节卡住了？卡住的原因是提示不清、流程缺失还是工具限制？下次怎么改？
比如我早期经常遇到 AI 生成的代码跑不起来，复盘发现是任务卡里没写清楚运行环境。后来我在任务卡模板里加了“运行环境”字段，问题就少了。再比如 AI 经常在多个文件之间改来改去，复盘发现是方案设计环节没定清楚文件边界，后来我在方案模板里加了“涉及文件清单”要求。
沉淀的载体就是前面说的资产层。项目宪法、任务卡模板、提示词库、变更日志，这四个文件构成了我的核心资产。每完成一个项目，我会把项目宪法里的通用部分抽出来，形成跨项目的基础宪法；把提示词库里好用的模板标记出来，形成个人最佳实践。这样下一个项目启动时，我不是从零开始，而是站在上一个项目的肩膀上。
4. 常见问题与排查技巧实录
4.1 AI 输出风格飘忽不定怎么办
这是最常见的问题。同一个项目里，AI 一会儿用驼峰命名，一会儿用下划线；一会儿返回字典，一会儿返回对象。根本原因是上下文里没有强约束。
排查思路分三步。第一步，检查项目宪法是否明确写了命名规范和返回格式，如果没写，补上。第二步，检查每次对话是否都贴了项目宪法，如果没贴，养成习惯。第三步，检查提示词里是否有“保持现有风格”的明确指令，如果没有，加上。
如果三步都做了还是飘，那可能是任务卡写得太粗。我的经验是，任务卡里把输入输出的数据结构写清楚，AI 的风格会稳定很多。比如明确写“输入是 User 对象，输出是包含 token 和 expire_at 的字典”，它就不会自由发挥。
还有一个技巧：在项目宪法里放一段“风格样例代码”，让 AI 照着写。样例代码不用长，一个函数就够，但效果立竿见影。
4.2 上下文太长导致 AI 变笨怎么处理
对话轮次多了之后，AI 会开始“遗忘”前面的约定，甚至自相矛盾。这不是模型的问题，是上下文窗口的物理限制。
我的处理方式是主动截断加摘要。当一个任务卡下的对话超过 10 轮，我就让 AI 先总结当前进展、已确认的决策、待解决的问题，然后开新对话，把摘要和项目宪法一起贴进去。这样既保留了关键信息，又释放了上下文空间。
另一个技巧是分层加载。项目宪法永远加载，任务卡按需加载，变更日志只在排查问题时加载。不要把不相关的历史对话一直挂着，那样只会稀释注意力。
如果任务特别复杂，我会把它拆成多个子任务，每个子任务独立对话，最后再合并。这比在一个超长对话里硬撑要可靠得多。
4.3 AI 生成的代码测试跑不过怎么排查
先别急着让 AI 改，按顺序排查。第一步，看错误信息是语法错误还是逻辑错误。语法错误通常是 AI 对语言版本不熟，比如用了新版本才有的语法。第二步，看是不是环境问题，比如依赖没装、路径不对。第三步，看是不是任务卡理解偏差，比如它以为输入是列表，实际是单个对象。
排查清楚之后，再决定让谁改。如果是理解偏差，回到任务卡，把输入输出写得更明确，然后重新生成。如果是语法或环境问题，直接把错误信息贴给 AI，让它针对性修复。如果是逻辑错误，先自己定位到具体函数，再让 AI 改那个函数，不要让它全局重写。
我踩过最大的坑是：错误信息没看全就丢给 AI，结果它基于不完整信息改了一通，越改越错。后来我养成习惯，先把完整错误栈读一遍，定位到文件和行号，再决定下一步。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 排查动作 | 预防措施 |
|---|---|---|---|
| 风格不一致 | 上下文缺约束 | 检查项目宪法和提示词 | 每次对话贴宪法，提示词加风格指令 |
| 上下文遗忘 | 对话轮次过多 | 让 AI 摘要后开新对话 | 分层加载，主动截断 |
| 测试跑不过 | 理解偏差或环境问题 | 读完整错误栈，定位文件和行号 | 任务卡写清输入输出和运行环境 |
| 改一处崩三处 | 文件边界不清 | 检查方案设计的文件清单 | 方案模板强制列涉及文件 |
| 无关改动多 | 提示词缺限制 | 检查是否有“只改相关代码”指令 | 提示词明确禁止额外重构 |
| 反复犯同一错 | 没沉淀错误模式 | 回顾变更日志 | 把常见错误写进提示词预防 |
4.5 几个反直觉的实操心得
第一个心得：AI 说“完成”的时候，往往是最危险的时候。因为它可能只完成了它理解的部分，而它理解的部分和你要的部分可能有偏差。所以每次它说完成，我都要对照任务卡的验收标准逐条检查。
第二个心得：不要让 AI 同时做设计和实现。我试过让它“设计并实现一个模块”，结果它设计得很粗糙，实现得很随意。后来我强制分两步，先设计后实现，质量提升明显。设计阶段它只需要想清楚，实现阶段它只需要写对，两个阶段的提示词和验收标准完全不同。
第三个心得：人工修改的代码也要让 AI 看一眼。有时候我手动改了几行，觉得没问题就提交了。后来有次让 AI 审查，它指出我改的地方引入了一个边界 bug。从那以后，我人工改完也会让 AI 过一遍，成本很低，收益很高。
第四个心得：框架越简单越能坚持。我一开始搞了很复杂的模板和流程，结果用了两周就放弃了。后来精简到四个文件、四类模板，反而坚持下来了。搭建框架的目的是减少认知负担，不是增加负担，如果框架本身让你觉得累，那一定是设计错了。
5. 框架的扩展与长期维护
5.1 从个人框架到团队规范
当这套框架在个人项目上跑顺之后，自然会想推广到团队。我的经验是：先跑通个人版，再抽象团队版，不要反过来。团队版和个人版最大的区别在于，团队版需要处理“多人上下文”和“决策共识”。
多人上下文的意思是，项目宪法不再是个人偏好，而是团队共识。我们当时的做法是，把项目宪法放进代码仓库，任何人修改都要走 review。任务卡也从个人文档变成 issue 模板，每个任务卡对应一个 issue，变更日志对应 PR 描述。这样 AI 协作的痕迹就自然融入了现有研发流程，不需要额外工具。
决策共识的意思是，AI 给出的方案需要团队确认才能落地。我们的做法是，方案设计环节的输出直接贴到 issue 里，团队成员评论后再进入实现。这样既保留了 AI 的效率，又保证了人的判断权。
5.2 框架的定期复盘与更新
框架不是一劳永逸的。我每季度会做一次复盘，问自己几个问题：这季度哪些环节最耗时？哪些提示词模板用得最多？哪些坑反复出现？然后针对性地更新项目宪法和提示词库。
复盘的时候我会翻变更日志，统计 AI 生成代码的返工率、人工修改的常见类型、测试失败的主要原因。这些数据不需要很精确，大概的趋势就够指导调整了。比如我发现某季度返工率上升，一查是任务卡写得太粗，那就加强任务卡的模板约束。
更新框架的时候，我遵循“小步快跑”原则，一次只改一个地方，改完用一个小任务验证，有效再保留。不要一次性大改，那样出了问题都不知道是哪个改动导致的。
5.3 这套框架不适合什么场景
说了这么多框架的好处，也得说说它不适合什么场景，免得你盲目套用。
第一，一次性脚本和探索性代码不适合。如果你只是写个临时脚本处理数据，或者在做技术调研，那直接对话生成就行，套框架反而累赘。框架的价值在于可重复、可维护，一次性任务不需要这些。
第二，紧急线上故障不适合。线上出问题了，第一优先级是恢复服务，不是走流程。这时候直接让 AI 帮你分析日志、定位问题、给出修复方案，快速验证上线，事后补变更日志就行。
第三，完全陌生的技术领域不适合。如果你对某个领域完全不了解，AI 说什么你都判断不了对错，那框架也帮不了你。这种情况下，先花时间学习基础知识，等有了判断力再用 AI 加速。
框架是工具，不是教条。它的目的是让你在 AI 协作中更稳、更快、更有积累，而不是让你被流程绑住。什么时候用、用多深，取决于任务的性质和你自己的判断。
我个人在实际操作中的体会是，这套框架最大的价值不在于它让 AI 变强了，而在于它让我变清醒了。每一步我知道自己在做什么、为什么这么做、做完之后留下了什么。AI 是个放大器，框架决定了它放大的是你的效率还是你的混乱。搭一套属于自己的框架，本质上是在梳理自己的工程思维，这件事本身就值得做。
