1. 当AI时代来临,开发者如何保持核心竞争力?
在当今AI技术飞速发展的时代,开发者们正面临一个前所未有的挑战:当AI能够快速生成代码时,我们的价值究竟在哪里?Boris Tane提出的"计划-执行分离"工作法给出了一个令人深思的答案。
作为一名长期与AI协作的开发者,我发现大多数同行都陷入了一个误区——过分追求AI的即时响应速度。我们习惯于向Claude等AI工具快速抛出prompt,期待立即获得可运行的代码。这种工作方式看似高效,实则让我们逐渐丧失了作为开发者的核心能力:系统思考和问题定义。
关键洞察:代码只是思想的执行,而思想本身才是创造力的核心。
2. 六步工作流详解:从混沌到有序
2.1 Research阶段:建立深度理解
与传统直接写代码的方式不同,Boris工作流的第一步是深入研究代码库。这个阶段的关键产出不是代码,而是一个详细的markdown文档,记录你对系统的理解。
我个人的实践发现,这个文档应该包含:
- 系统架构图(用文字描述)
- 核心模块的功能说明
- 已知问题和潜在改进点
- 外部依赖和约束条件
这个文档会成为你与AI协作的"共享上下文",避免了在后续交流中反复解释背景的麻烦。
2.2 Plan阶段:设计而非编码
在拥有扎实的研究基础后,才开始制定计划。这里有一个重要原则:永远不要让AI在review和approve书面计划之前写代码。
我通常会在markdown中规划:
- 功能变更的影响范围
- 需要修改的模块清单
- 预期的接口变化
- 测试策略
这种书面化的计划过程强制你进行系统性思考,而不是直接跳入实现细节。
2.3 Annotation阶段:校准AI理解
这是整个工作流中最具创新性的环节。你需要:
- 将初步计划发送给AI
- 仔细阅读AI的反馈
- 在文档中添加inline notes回应AI的问题
- 重复1-3步,通常需要3-5轮迭代
通过这种"对话式注解",你和AI对问题的理解会逐渐趋同。我发现在这个阶段投入的时间越多,后续实现阶段的问题就越少。
2.4 Todo List阶段:任务拆解
当计划足够成熟后,将其转化为具体的待办事项。我的经验是:
- 每个任务应该足够小(2-4小时工作量)
- 明确任务间的依赖关系
- 为每个任务定义验收标准
- 标注可能需要AI协助的部分
2.5 Implement阶段:让AI执行
这是整个流程中最"无聊"的部分——让AI根据详细的计划生成代码。由于前期工作充分,这个阶段通常很顺利。
我的实践建议:
- 一次性提供完整上下文(之前的所有文档)
- 明确代码风格要求
- 设定合理的代码审查标准
- 保持适度监督,但不要过度干预
2.6 Feedback阶段:闭环学习
代码运行后,将结果反馈到研究文档中,形成知识积累。我通常会记录:
- AI生成的代码中需要人工调整的部分
- 实际运行与预期的差异
- 下次可以优化的地方
3. 一人公司的生存之道:构建人机协作操作系统
3.1 为什么这套方法适合独立开发者?
作为独立开发者,我们最大的挑战不是技术能力,而是如何高效管理有限的注意力资源。Boris的工作流通过明确划分"思考"和"执行"阶段,实现了:
- 注意力保护:避免在编码和设计之间频繁切换造成的认知负荷
- 知识沉淀:所有思考过程都被文档化,形成可复用的知识资产
- 质量可控:通过前期充分的计划降低后期返工的概率
3.2 实操中的经验教训
经过半年多的实践,我总结了以下关键经验:
- 文档即产品:你的markdown文档应该像代码一样精心维护,它是你思考过程的具象化
- 节奏控制:每个阶段都要设置明确的时间盒,避免在某个环节过度优化
- 工具链整合:将这套流程与你日常使用的IDE、版本控制工具深度集成
- 度量改进:记录每个阶段的耗时和质量,持续优化工作流程
4. 超越代码:AI时代的开发者思维升级
4.1 从编码者到系统思考者
这套方法最深远的影响是重新定义了开发者的核心价值。当AI可以快速生成代码时,我们的竞争优势转向:
- 问题定义能力
- 系统分解能力
- 方案权衡能力
- 质量把控能力
4.2 实际案例:重构一个遗留系统
最近我用这套方法成功重构了一个10年历史的代码库。整个过程耗时3周,其中:
- 研究阶段:5天
- 计划阶段:4天
- 注解阶段:3天
- 实现阶段:3天
- 反馈阶段:2天
虽然前期投入了大量时间,但最终的重构一次成功,没有出现常见的回归问题。这验证了"慢就是快"的哲学。
5. 工作流定制与工具选择
5.1 个性化调整建议
虽然Boris的六步框架很完整,但根据项目特点可以做适当调整:
- 小型项目:可以合并研究和计划阶段
- 紧急修复:可以直接从Todo List开始,但事后要补充文档
- 探索性项目:增加原型设计阶段
5.2 我的工具栈配置
经过多次迭代,我目前的工具配置如下:
| 阶段 | 工具 | 使用技巧 |
|---|---|---|
| 研究 | Obsidian | 使用双向链接建立知识图谱 |
| 计划 | VS Code + Markdown | 利用代码片段快速生成模板 |
| 注解 | Google Docs | 利用批注功能与AI互动 |
| 待办 | Trello | 与GitHub Issues同步 |
| 实现 | GitHub Copilot | 配置自定义提示词模板 |
| 反馈 | Notion | 建立可检索的知识库 |
6. 常见问题与解决方案
6.1 如何避免过度设计?
这是初期最容易犯的错误。我的应对策略是:
- 为每个设计决策设置"为什么"检查点
- 采用"刚好够用"的设计原则
- 定期回顾并简化文档
6.2 当AI不理解复杂业务逻辑时怎么办?
遇到这种情况,我会:
- 创建业务术语表
- 绘制流程图或状态机图(文字描述)
- 提供典型用例示例
- 分步骤解释核心算法
6.3 如何衡量各阶段的完成度?
我建立了简单的检查清单:
研究阶段完成标准:
- 所有核心模块都有描述
- 关键数据流被文档化
- 已知问题被明确列出
计划阶段完成标准:
- 变更影响分析完整
- 测试策略明确
- 风险评估到位
7. 进阶技巧:提升AI协作效率
7.1 提示词工程优化
经过大量实践,我总结出几个有效的提示词模式:
- 角色设定:"你现在是一个资深的[语言]开发者,正在参与[项目类型]项目..."
- 约束明确:"在实现时请遵循以下原则:1... 2... 3..."
- 格式要求:"请用markdown格式返回,代码部分用```包裹"
7.2 上下文管理技巧
与AI协作最大的挑战是上下文丢失。我采用以下策略:
- 维护一个"主文档"包含所有背景信息
- 每次交互都引用相关章节
- 定期进行"上下文压缩"(总结长篇讨论)
- 使用唯一的标识符标记重要概念
8. 从理论到实践:我的日常工作安排
为了让这套方法真正落地,我设计了以下每日工作节奏:
上午(深度思考时段)
- 9:00-10:30:研究阶段
- 10:30-12:00:计划阶段
下午(执行时段)
- 13:00-15:00:注解迭代
- 15:00-17:00:实现与测试
晚间(反思时段)
- 20:00-21:00:反馈与知识整理
这种安排确保了思考与执行的明确分离,避免了常见的上下文切换成本。
在AI时代,开发者需要重新定位自己的价值。Boris Tane的"计划-执行分离"工作法不仅是一套技术流程,更是一种思维方式的升级。通过将创造性工作与机械性工作明确分离,我们既能充分利用AI的效率优势,又能保持人类在问题定义和系统思考方面的独特价值。
这套方法的精髓不在于具体的六个步骤,而在于它所体现的核心原则:在适当的时候做适当的事。作为独立开发者,当我们能够清晰划分"思考"与"执行"的边界,并善用AI工具时,一个人确实可以像一个高效团队那样工作。
