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.11FastAPI 0.104Poetry 管理依赖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 是个放大器框架决定了它放大的是你的效率还是你的混乱。搭一套属于自己的框架本质上是在梳理自己的工程思维这件事本身就值得做。
