AI原生开发流程复盘：人从执行者变指挥官
前几天我为自己的字幕转录翻译工具新增了一项远程转录功能，整个开发流程颇具代表性，值得完整复盘。不少人对AI辅助开发的认知还停留在“让AI替我写代码”的层面，这个理解不算错，但并不全面。写代码在整个软件开发流程中只是其中一个环节，在AI时代，它反而是变化最小、最不需要费心的环节——当下的大模型在编码领域已经打磨得十分成熟，仅靠简单的自然语言提示词就能生成合格的代码。真正带来颠覆性改变的，是代码之外的流程：需求梳理、方案设计、原型制作、测试验证这些环节，才是AI原生开发重构行业规则的核心所在。
核心认知：流程未变，角色已换
在展开具体流程之前，先明确一个最关键的认知：AI原生开发并没有发明一套全新的软件开发流程，其核心步骤依然是可行性分析、方案设计、原型制作、编码实现、测试验证，一个环节都不会少。真正改变的，是每个环节的执行主体。
传统开发中，每个环节都由人类亲手完成。而在AI原生开发中，人类的角色转变为指挥官，AI助手则成为具体的执行者。人类只需要在关键路径上做确认和决策，具体的分析、设计、编码、调试等工作，全部交给AI助手完成。打个比方：你从一线程序员升级成了技术总监，不再需要编写每一行代码，但需要决定要不要做、怎么做、做得对不对。当你真正跑通一遍完整流程后，会发现效率提升是数量级的。
需求起源：来自真实用户的反馈
这次的需求起源于一条用户反馈，用户在项目仓库留言，希望能为工具添加远程转录功能。具体场景是：用户拥有两台电脑，一台性能强劲、算力充足，另一台用于日常办公。他希望在办公电脑上使用工具时，将需要大量算力的转录任务交给性能更好的电脑完成。这个需求场景合理，能为用户带来实际价值，也和产品定位高度契合，因此我认为值得推进，但并没有立刻开始写代码。
第一步：可行性分析，先判断要不要做
这是整个流程中最容易被跳过，但又绝对不能省略的关键步骤。很多人都有过盲目开工最后返工的经历，我也曾因为跳过细致判断，做过一个本地文本模型辅助字幕拆分对齐的功能，当时觉得技术上完全可行，但实际体验后效果极差，最终只能放弃，浪费了不少时间和资源。即便有时可行性判断会出现失误，但这个步骤依然能帮我们避开绝大多数弯路，本质上是对开发价值的一次提前校验。
可行性分析通常需要从两个维度展开：一是产品层面，这个功能是否有实际价值，是否和产品定位匹配；二是技术层面，能否实现该功能，开发成本是否可控。
这次的需求在产品层面已经通过了校验，因此我将重点放在技术可行性判断上。我将用户的原始需求发给AI编码助手，让它结合项目现状做技术分析。AI很快给出了可行的判断，并列出了三个技术方案：
- 方案0和方案C不需要修改现有代码，但需要用户自行搭建ASR服务器，对普通用户来说门槛过高，操作起来非常复杂；
- 方案A最为简便，用户仅需安装工具就能启动本地转录服务，对用户最友好；
- 方案B对Windows系统的适配性不足。
最终我选择按方案A推进，同时将方案0中的HTTP转录API作为附加功能一并实现。这里的核心模式是：AI负责分析和罗列方案，人类负责最终的判断和决策。我们不需要深入研究每个技术方案的细节，但需要结合自身的产品经验和技术直觉做出最终选择。
第二步：编写设计文档，搭建跨环节沟通桥梁
确定了技术方向后，我依然没有立刻开始写代码，而是先让AI生成设计文档。这涉及到AI原生开发的一个核心认知：文档在这个时代已经拥有了全新的角色，它是人类和AI助手之间、以及不同AI会话之间的沟通桥梁。
在传统开发流程中，文档往往是附加品，写完之后很快就会过时，很少有人会主动查阅。但在AI原生开发中，文档变成了核心的中间媒介，原因有两点：
- 第一，文档是人类确认和修改方案的载体。AI将技术方案整理成文档后，我们可以快速通读，确认方向是否正确，细节是否存在问题，并直接在文档中进行修改。
- 第二，文档是不同AI会话之间传递上下文的媒介。每个AI会话的上下文窗口都有限，当我们从设计环节进入开发环节时，通常会开启一个新的会话，前一个会话的思考过程、决策依据和技术方案，都需要通过文档传递给新的会话，否则新的会话就需要重新梳理所有背景信息，相当于从零开始。
简单来说，文档就是AI原生开发中的“记忆载体”。
我这次生成的设计文档混合了产品设计和技术设计两部分内容，清晰描述了需求细节、整体架构和接口定义，目的是将所有关键信息固化下来，既为后续的开发提供明确的参照，也为人类提供了一个可以校验方向的锚点。
理想状态下，每个阶段结束后都应该生成可留存的交付物，比如需求文档、设计方案、原型、代码和测试报告，并且将这些交付物和版本管理工具结合，跟踪所有变更，这样这些交付物还可以作为审计记录，清晰展示需求提出者、AI产出内容和最终审批人。
这次我稍微简化了流程，写完设计文档后直接进入原型制作环节，主要是因为前期的可行性分析已经给出了明确的方案，且我对当前使用的AI开发工具比较信任。但如果是更复杂的项目，仔细审查设计文档的成本远低于写完代码后再推翻重做。
还有一个关键的操作细节：经过确认的文档，就是下一个AI会话的全部起点。当我们从设计环节切换到开发环节时，不需要再向AI重新解释整个来龙去脉，只需要一句话“按照设计文档实现”即可，文档中已经包含了所有决策和细节，新的会话可以直接基于文档开始工作。
第三步：高精度原型制作，整合需求、原型与UI
这是AI原生开发中变化最大的环节之一。在传统流程中，需求文档、原型设计和UI设计是三个独立的步骤，分别由产品经理、交互设计师和UI设计师完成，每一次交接都会产生信息损耗，每一次修改都需要多方协调，成本极高。
在AI的加持下，这三个步骤可以合并为高精度原型制作：产出的原型不再是简单的线框图，而是接近最终成品的高保真设计，直接包含了交互逻辑和视觉效果。在以前，这几乎是不可能的，因为很少有人能同时具备产品思维、交互设计和UI设计的能力，即便有，制作一个高保真原型也需要数天时间。但现在，只需要一个AI助手搭配合适的设计工具，就能快速产出高精度原型。
我的工具配套了专属的原型设计页面，每次新增或修改功能时，都会先更新原型。有了设计文档作为基础，原型制作过程相对顺利，第一个版本的原型在设置页面新增了一个选项卡，用于开启转录服务和发现网络中的其他节点。
但原型完成并不代表万事大吉。原型阶段的修改成本极低，而一旦产品开发完成再修改界面，成本会呈指数级上升，不仅需要修改代码逻辑，还要调整样式、状态管理和测试用例。因此，这个阶段值得反复打磨。
我对原型进行了多轮调整：首先将布局从列表形式改为Tab页签，将“开启服务”和“访问其他节点”两个功能分开，因为这是两个完全不同的使用场景，混在一起会让用户感到困惑；随后添加了服务状态图标，让用户可以一眼看出服务是否正在运行。后来我又发现，将该功能放在设置页面中不够便捷，用户需要频繁查看服务状态，藏在设置里太深了，于是又将它移到了主界面。经过多次调整后，最终的原型才达到了满意的效果。
这里的核心模式是：每次调整只需要用自然语言描述想要的变化，AI就会修改原型。我的注意力完全放在“交互是否友好”“界面是否美观”“用户使用是否自然”这些产品层面的判断上，而不需要纠结像素和布局的实现细节。
之所以不建议跳过原型确认环节，正是因为界面和交互一旦开发完成，修改成本极高，而在原型阶段，调整一个布局可能只需要一句话就能完成。
第四步：代码实现，编码不再是开发瓶颈
当我们手中已经有了设计文档和确认后的高精度原型，让AI生成代码对于当前的大模型来说已经是一件非常简单的事情。
我配合自动化任务命令，将设计文档和原型一起发给AI编码助手，让它按照文档中的规划逐步实现功能。AI会自行规划实现顺序，编写代码，运行测试，甚至会自动截图验证效果。
这里有一个容易被忽略但非常重要的技巧：让AI自行完成验证，可以减少人类介入的次数。AI写完一段代码后会自动运行测试，如果发现失败会自行调试修复；修改完界面后会自动截图确认效果。这相当于给AI建立了一个自我反馈循环，让它在人类最终确认之前先完成自我检查，这样我们拿到的已经是经过AI验证的结果，而不是粗糙的初稿。
这也是为什么我们可以合并一些确认环节，比如跳过代码审查直接进行黑盒测试。当前的AI助手能力已经足够强大，加上开发过程中的自我验证，产出的代码质量已经很高。
在这个阶段，人类需要做的事情非常少，主要就是等待进度，偶尔查看一下进展即可。
仔细思考后会发现，代码已经不再是开发流程的瓶颈。在传统流程中，PRD文档、开发估算、安全审查等环节都是为了在开发阶段前做好对齐，因为开发可能需要数周甚至数月时间。但当AI可以在数小时内完成编码时，传统的确认流程就需要重新审视了。
当下的开发瓶颈已经转移到了代码两侧：左侧是设计和确认环节，右侧是测试、验证和部署环节。这些环节依然需要人类手动完成，速度较慢，也是当前需要重点优化的部分。这也是为什么我在前面的可行性分析、设计文档和原型制作上花费了大量篇幅——在AI原生开发中，这些代码之前的工作反而才是最重要的。
第五步：测试验证，切换为普通用户视角
即便AI会帮我们编写测试用例、运行测试并验证结果，我们也不能完全依赖AI，还需要亲自上手体验。
这里的关键心态转变是：把自己当成普通用户，而不是开发者。开发者测试和用户测试的视角完全不同，开发者会下意识地避开边界情况，按照自己预期的路径操作，但普通用户不会，他们会随意点击、输入意想不到的内容，用我们从未预想过的方式使用功能。
因此，我们需要做的是：打开工具，假装自己是第一次接触这个功能，凭直觉去使用它，看看提示是否清晰，交互是否自然，出错时是否有合理的引导。
发现的问题直接交给AI修复，经过几轮调整后，功能就基本可以正常使用了。
我这次并没有审查代码，而是将自己当成QA，只做了黑盒测试，因为我信任当前的AI编码工具的能力。这也是前面提到的“合并确认环节”的具体体现：AI在开发过程中已经自行运行测试并验证了结果，再加上我从用户视角进行的一轮黑盒测试，两层验证已经足够。当然，这个取舍取决于项目的重要程度，如果是金融系统这类核心业务，还是需要进行代码审查，但对于大多数普通功能开发来说，黑盒测试已经足够。
深层思考：三个本质变化
回头来看整个开发流程：
可行性分析 → 设计文档 → 原型设计 → 编码实现 → 测试验证
这和传统的软件开发流程完全一致。AI原生开发并没有发明新的流程，而是用全新的方式运行旧的流程，具体有三个本质变化：
1. 执行主体从人类变为AI助手
每个环节的具体执行工作都由AI助手完成，我们不需要自己编写可行性分析报告、绘制原型图、编写代码或测试用例，只需要在关键节点进行确认和决策。我们将精力集中在判断和决策上，而AI助手负责处理具体的执行和细节。
2. 确认环节可以合并，但绝对不能省略
传统流程中，需求确认、原型确认和UI确认是三个独立的评审会议。现在我们可以将它们合并，将需求文档、原型设计和UI设计整合为高精度原型，一次性完成确认，设计文档和原型也可以放在一起审查。但确认环节本身绝对不能省略，每个确认步骤都有其存在的意义：
- 可行性确认：先决定是否要做，避免投入大量时间后发现毫无价值
- 技术方案确认：确认当前方向是否最优，是否存在更好的实现路径
- 原型/UI确认：确认交互是否友好、界面是否美观，毕竟开发完成后再修改成本极高，而原型阶段修改非常容易
- 测试确认：站在用户视角验证功能是否好用，而不是站在开发者视角验证是否能运行
我们可以加速确认流程，合并环节、简化步骤，但绝对不能跳过确认，人类的判断力是整个流程中不可替代的部分。
3. 文档的重要性大幅提升
在传统开发中，文档只是附属品，通常是代码写完后再补写，甚至完全不写。但在AI原生开发中，文档已经成为核心基础设施，承担两个关键职能：
- 第一，作为人类确认和修改的载体，我们可以审查设计文档、批注原型、修改技术方案，所有的调整都在文档层面完成。
- 第二，作为不同AI会话之间传递上下文的媒介，设计文档会被传递给开发会话，原型会被传递给实现会话，让每个AI会话不再是孤立的，不需要重复解释背景信息。
当然，文档也会带来新的问题，如果没有及时更新版本，反而会传递错误的上下文信息。
关于工具技能的反常识观点
最后聊一个很多人关心的话题：我们需要使用多少开发类工具技能来增强AI助手的编码能力？
我的答案可能会出乎很多人的意料：大多数开发类技能其实没有必要。当下的大模型在编码领域已经打磨得十分成熟，我在整个流程中使用的都是非常简单的自然语言提示词，比如“帮我分析一下需求的可行性”“按照方案编写设计文档”“根据这个设计制作原型”“按照文档实现功能”，并没有使用复杂的提示词工程或特殊的编码技能。
前面我们提到，开发瓶颈已经转移到了代码两侧，编码本身已经不需要额外增强，真正需要增强的是代码两侧的环节：左侧的设计确认，以及右侧的测试验证和部署。
我通常只会使用两类技能，正好对应这两个瓶颈：
- 第一类是辅助设计确认的技能，用于解决左侧瓶颈。比如将原型设计和UI设计合二为一的工具，这类工具可以帮助我们快速产出高精度原型，让我们在编写代码之前就能确认界面和交互效果。
- 第二类是自动化减少体力劳动的技能，用于解决右侧瓶颈。比如自动部署、自动发布这类工具，编码完成后还有打包、部署、发布等环节，这些不需要判断力，但非常耗时；还有自动化任务命令，可以让AI按照里程碑自动推进开发，减少我们手动拆分任务的工作量。
至于编码本身，当前的大模型已经足够优秀，只需要简单的指令就能生成高质量的代码。将精力花在流程设计上，比花在提示词优化上的回报要大得多。
写在最后
回顾整个远程转录功能的开发过程，从用户反馈到功能完整可用，我几乎没有花费时间编写代码，反而在可行性判断、原型反复打磨和站在用户视角测试上花费了最多的时间。这些恰恰是AI助手无法替代的部分：是否要做这个功能、方向是否正确、功能是否好用，每一个都需要人类来做最终决策。
AI原生开发的精髓也正在于此：开发流程依然是老样子，但人类的角色发生了彻底改变。我们从编写代码的一线开发者，变成了管理AI助手的指挥官，我们的产出不再是一行行代码，而是一个个判断和决策。
我知道放下对代码的执念并不容易，尤其是写了很多年代码的开发者，不查看每一行代码就合并功能，心里总会感到不踏实。我也是经过一步步适应才达到了“只做黑盒测试”的状态。但趋势已经非常明确：大模型的编码能力只会越来越强，人类的价值会越来越集中在代码两侧的环节。越早完成角色转换，我们就能从AI中获得越大的效率杠杆。
