开发实践分享
这一年，我是怎么
和 AI 一起做开发的
从交给 AI 写代码，到一起推进完整任务
之前我先定方案、拆任务，AI 再实现
现在一起讨论方案、推进任务、检查结果
个人实践分享 · 2026 年 10 月
协作方式是怎样变化的
从辅助写代码，到一起讨论和推进任务。
01 · 协作方式是怎样变化的模式回顾 · 1/3
先回顾：四种协作模式
问答与片段
描述局部问题
生成函数、类型或解释
人整合并检查
编辑器补全
利用当前文件
补齐重复结构
人决定写什么
项目内协作
阅读多个文件
共同定位与修改
人参与分析与取舍
按方案完成任务
人先定方案、拆任务
AI 负责具体实现
人审查代码、测试验收
这些方式可以并用，按当前任务选择。
01 · 协作方式是怎样变化的今年的实践 · 2/3
今年：先看任务，再决定怎么做
范围清楚、容易回退
直接执行，再验证结果
业务仍有歧义
先探索与对齐，再确定方案
跨会话推进、错误后果较大
增加计划、阶段验收与人工检查
先弄清问题和完成标准，再决定要不要写方案、列计划。
01 · 协作方式是怎样变化的任务怎样交接 · 3/3
复杂任务的三个阶段
对齐需求与方案
形成可验收计划
执行与结果验收
人类判断
业务假设、必要复杂度
交接产物
确认后的技术方案
人类判断
顺序、依赖、完成条件
交接产物
计划与进度约定
人类判断
必要决策、结果与风险
交接产物
结果、证据、未完成项
可以在同一会话内完成，也可以通过文件交接；小任务可以合并阶段。
先把需求和方案想清楚
把业务条件说清楚，决定这次需要做到什么程度。
02 · 先把需求和方案想清楚虚构需求：批量导入 · 1/2
先对齐代码里看不到的条件
假设：为资料整理工具增加批量导入功能
文件与规模
支持哪些格式？
每批处理多少资料？
业务与失败处理
重复内容怎样处理？
失败后怎样重试？
先只读探索，列出不确定的业务假设，
确认后再完善最小方案。
本页及后续导入场景均为方法演示中的虚构设定。
02 · 先把需求和方案想清楚人类在哪里判断 · 2/2
架构审查，也包括做减法
假设条件
单人、本地、小批量
每批几十条资料
失败项允许手动重试
这时的做法
顺序处理，人工重试
列清失败项及原因
只补传失败项
关闭页面后继续执行 → 后台处理
中断后继续 → 保存任务进度
把任务推进到完成
确认计划、持续执行，在沟通与验证中把任务做完。
03 · 把任务推进到完成从方案到计划 · 1/4
计划要写出完成条件
文件解析
导入处理
结果提示
回归检查
每个阶段
目标、依赖、验证方式
完成条件、证据位置
整个任务
约定样例能够完成导入
有效、重复、无效记录按约定处理
计划说明怎样判断完成，进度记录当前做到哪里。
03 · 把任务推进到完成长程任务 · 2/4
让执行可以继续，也可以恢复
计划文件
保存目标与约定
范围与选择理由
阶段及整体验收条件
进度文件
保存当前状态
已完成项与证据
阻塞、未完成项、下一步
已有授权范围内持续推进；遇到必要决策时，带具体问题与可选处理交接给人。
03 · 把任务推进到完成一起讨论与修改 · 3/4
像和同事一样，把问题说清楚
补充背景
说明使用场景、业务限制和已有约定
讨论取舍
说清为什么这样选，哪些暂时不做
具体反馈
指出哪里与预期不同，约定怎么改、怎么检查
把背景、理由和预期说清楚，再一起修改和验证。
03 · 把任务推进到完成开发与联调 · 4/4
开发时用 Mock，完成后再联调
开发阶段
用 Mock 跑通本地流程
替代登录、接口等外部依赖
固定数据，反复修改与验证
覆盖成功、失败、超时等返回
联调阶段
接入真实服务
检查接口约定、鉴权与数据保存
验证完整业务链路
确认实际行为符合开发时的预期
先让开发过程不依赖外部服务，再用真实链路检查集成。
把经验留在项目里
积累开发资产和项目知识，让后续任务有现成的准备。
04 · 把经验留在项目里项目长期积累 · 1/3
把开发准备留在项目里，后面接着用
启动脚本、Mock、固定测试数据
测试命令、任务目录与端口约定
日志、错误信息、截图入口
构建与测试结果的查看方式
重置测试数据、重启服务、恢复任务
清理临时改动的操作说明
让下一次开发能直接复用，少重复准备、少从头解释。
04 · 把经验留在项目里上下文与执行准备 · 2/3
让 Agent 按需找到项目知识
上下文工程：找到正确的信息
Harness Engineering：支持执行、验证、观测与恢复
当前任务资料
方案、计划、进度
调试材料与验收证据
长期项目知识
业务约束、架构理由
运行指南与相关技能
按任务读取需要的材料，避免默认加载全部文档。
04 · 把经验留在项目里持续维护 · 3/3
任务结束后，提炼仍然有效的知识
任务资料
核对适用范围
提炼并回写
长期知识
代码外的约束
业务、环境和外部条件
重复推导的信息
模块关系与运行方式
选择的理由
为什么这样做、何时重评
用下来遇到的问题与反思
消息和输出变多、开发加快之后，人的审阅与后续交付怎样跟上。
05 · 用下来遇到的问题与反思通知与注意力 · 1/3
消息和输出多了，人还是要逐项看
不断增加的内容
进度、通知、代码、文档
多个机器人和任务同时发消息
改动和说明等待人来阅读
人要完成的工作
找重点、理解、判断
哪些消息需要我处理？
哪些结果需要仔细审查？
需要决定、出现阻塞或影响交付时再通知；
普通进度集中汇总，过程细节按需查看。
同时开多少任务，也要考虑自己能审阅多少结果。
05 · 用下来遇到的问题与反思输出与交接 · 2/3
发给别人之前，先整理成对方需要的内容
直接转发整段 AI 输出
接收方继续找答案
找结论、补背景
核对事实、猜下一步
核对和取舍后再交接
说明对方需要处理什么
我的判断、依据和不确定项
需要的决定与下一步
内容看起来完整，却把理解、筛选和核对的工作
留给了接收方。
我发出去的内容，先由我读懂、核对，再作取舍。
05 · 用下来遇到的问题与反思开发与交付 · 3/3
代码写得快，评审和测试仍要排期
开发实现
代码评审
测试与联调
发布与验收
后面仍在等待
待评审的改动、可用的测试环境
回归检查、业务确认与发布安排
需要一起调整
提前准备验证与交接条件
按可验收部分推进，控制同时在做的任务
除了开发耗时，也看后面等了多久、返工了多少。
回看这一年
回顾一起做事的方式，也把审阅、沟通和交付放进考虑。
回看这一年
把任务做完，也把结果交代清楚
从我先定方案、拆好任务，再交给 AI 实现，
到一起讨论、推进和验证，也关注人怎样审阅和接手。
人来判断
业务范围与方案取舍
结果是否符合预期
一起推进
方案、计划、实现和验证
按可验收部分交接
项目积累
可复用的脚本、数据与知识
清楚的通知和交接约定
让后续开发有准备，让接手的人看得明白。