7.0
热点
AI SCORE
编程提效2026-01-24 06:35
实战工作流：我的 AI 辅助开发效率方法论
DEV Community · Ola Prøis#工作流#提示工程
Editor brief · 编辑速览
开发者详细分享在真实项目中的 AI 编码工作流，包括工具选型、提示工程、协作模式等可复用的经验。
开发者详细分享在真实项目中的 AI 编码工作流，包括工具选型、提示工程、协作模式等可复用的经验。
我用AI构建软件已经有一段时间了。多个仓库、不同的技术栈，有些失败、有些成功上线的产品。在这个过程中，我开发了一套真正有效的工作流程。
这不是理论。这是我在尝试了一堆不太有效的方法后，真正落地的结果。
我最开始的做法是打开聊天窗口，描述我想要什么。有时有效，但更多时候我得到差不多可以用的代码，花好几小时调试，聊天变长了就失去上下文，最后只能重新开始。
AI本身不是问题。我的流程是。
我需要结构。一种分解工作、在会话间维持上下文、验证结果而不用逐行读代码的方法。
在写任何代码之前，我和不同的AI助手讨论这个想法。Claude来处理架构，Perplexity来研究库和方案，有时还用Gemini换一个视角。
每个AI都有盲点。一个推荐某个库，另一个却知道它有问题。一个提出某个架构，另一个发现它为什么扩展不了。花5分钟听听不同意见，可以省掉后面好几小时的试错。
Task Master需要一份产品需求文档(PRD)来生成任务。这不只是走流程，PRD的质量直接决定了生成任务的质量。
初步讨论后，我让某个AI起草一份PRD。它捕捉问题、功能和具体的验收标准。"添加搜索"不再是一句话，而是一份结构化文档，包含快捷键、UI行为、边界情况和技术考量等章节。
然后我用其他AI来审查这份PRD。Claude可能发现遗漏的边界情况。Gemini可能质疑某个架构决策。Perplexity可能标出我提到的某个库有已知问题。
我反复改进。有时是快速微调，有时是根本性的重新思考。每一轮迭代PRD都会更紧凑。
只有当我对规范有信心了，才把它提给Task Master。花在精化PRD上的时间立刻就有回报——生成的任务具体清晰、顺序正确、真的能干。
当AI准确知道"成功长什么样"时，它写出来的代码好得多。模糊的需求→模糊的任务→模糊的代码。清晰的PRD→清晰的任务→能用的代码。
大功能需要拆分。我用Task Master(一个MCP工具)来解析需求，生成带依赖关系的结构化任务列表。
它把一个功能变成一系列步骤，每个任务都有明确的输入、输出和前后顺序。AI知道该先做什么、什么依赖什么。
你不一定要用Task Master。重要的是有明确的任务，而不是模糊的目标。
AI模型有训练截止日期。它们知道的库文档可能过时了。我用Context7(另一个MCP工具)把最新文档拉进上下文。
仅这一点就能消灭一整类bug。再也不会遇到"为什么这个API不存在"或"这个方法早就弃用了"的问题。AI用的是准确的信息。
两个文件能显著改善AI写出符合你项目风格的代码。
ai-context.md 是一个精简的架构参考，我控制在100行以内。它告诉AI怎样写符合代码库的代码：模块结构、关键类型、语言习惯、框架风格，还有那些容易掉坑的地方。重点不是做什么(那来自交接)，而是怎样写出"属于这个项目"的代码。
index.md 是文档地图。所有技术文档按类别整理，每条一行描述。AI需要理解某个东西怎么工作时，能快速找到对应文档，而不是瞎猜或问我。
这两个文件很快就值回票价。AI写的代码和现有风格一致，而不是另起炉灶。它从文档找答案，而不是凭空编。
这是对我工作流程改进最大的地方。
AI助手记不住之前的对话。我没反抗这一点，反而利用它。每个任务开一个新聊天。我粘贴一份交接文档，里面是这个任务需要的一切：规则、相关文件、当前任务。
为什么要新聊天？旧上下文会积累噪音。三个任务下来，AI就会引用之前的无关内容。重新开始，用专注的交接，效果更好。
新建聊天，粘贴交接
完成任务
粘贴 update-handover-prompt.md，AI会更新下一个任务的交接
我保持交接简洁，但通常在当前交接文档里放一些规则——这份我粘贴到每个聊天里。只保留当前任务需要的。不要项目总览，不要前面任务的细节，除非直接相关。
我不逐行读代码。我运行它，看看能不能用。
功能做的是我要求的吗？它处理边界情况吗？它把别的东西搞坏了吗？
有问题时，我描述现象。AI从那儿开始调试。
这个分工效果不错。AI负责代码质量，我负责产品质量。
我用这套流程试过好几种语言。Rust特别突出。
编译器非常严格。真的很严格。代码还没运行，就能捕捉整个类别的bug。内存问题、类型不匹配、生命周期问题。AI可以写代码、编译一下，立刻拿到反馈——什么坏了，在哪儿。
用动态语言的话，bug躲到运行时。你跑代码、遇到错、描述给AI、等修复、再跑一遍。Rust编译器直接告诉AI具体什么坏了。反馈循环更紧。
AI在Rust里也倾向于写更安全的代码，因为语言强制。编译器不许你忽视Result，所以你不会意外漏掉错误处理。防护栏是内置的。
这不是说Rust是唯一选择。但如果你要用AI构建实质性的东西，一个编译器严格的语言是真正的优势。
具体的需求。模糊的问题产生模糊的结果。花时间把需求说清楚，立刻就有收益。
任务大小。对Claude Opus 4.5这样的能力型模型，我能在一个会话里搞定整个功能。对早期的或体量小的模型，把东西分成更小的块，中间用交接。两个方案都行，就是速度有差别。
多个视角。不同AI捉到的问题不一样。第二意见花的那几分钟值。
交接系统。好的上下文文档决定了一个会话是高效还是令人沮丧。这个我花的时间最长才摸透。
真的去测试。AI会信心满满地说"应该能用"，但其实不行。信任但验证，每回都是。
AI会漏掉人类能捕捉的边界情况。有时过度设计。维护交接文档得费力。
还有一个技能门槛——怎样把这些环节协调好。什么时候分解得更细、带什么上下文、怎样清楚地描述bug。这需要时间积累。
我关注的是应该做什么、做得对不对。AI负责怎么做。
那算"编程"吗？不知道。我知道的是，这套流程能交付有效的软件，我个人是做不出来的。
具体用什么工具不如流程本身重要。结构化你的工作，写清楚需求，保持上下文，验证结果。AI搞定其余的。
我已经在我的一个项目里详细记录了这套工作流程和例子。Ferrite这个repo包含了我用的PRD、任务文件、交接模板、ai-context.md和文档索引。如果你想看这套方法实际长什么样，或者要拿模板给自己项目用，可以看 docs/ai-workflow/。
一些评论可能仅对已登录用户可见。登录后查看所有评论。
如需进一步操作，你可能想屏蔽此用户或举报滥用行为。