需求转技术任务
优先试点这一场景的目标是把需求、现有架构、约束和验收标准整理成技术方案、任务拆分和风险。
- 输入
- 需求、现有架构、约束和验收标准
- 输出
- 技术方案、任务拆分和风险
- 验收
- 检查文档耗时、测试覆盖变化、代码审查问题命中率
- 边界
- 架构取舍和范围由研发负责人确认

程序员岗位适合让AI智能体承担理解、文档、测试和审查辅助,生产代码仍要经过工程验
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 需求转技术任务 | 需求、现有架构、约束和验收标准 | 技术方案、任务拆分和风险 | 架构取舍和范围由研发负责人确认 |
| 代码生成与补全 | 代码库上下文、接口、规范和测试 | 候选代码和修改说明 | 不得只凭片段生成后直接合并 |
| 代码审查 | 变更、规范、威胁模型和历史问题 | 缺陷、风险、证据和建议 | AI审查是补充,关键代码仍需人工Review |
| 单元与集成测试 | 代码、接口契约、边界和历史缺陷 | 测试用例、Mock、覆盖缺口 | 测试通过不等于业务正确 |
| 缺陷定位与修复 | 日志、堆栈、复现步骤、代码版本 | 根因假设、验证步骤和补丁 | 先复现再修复,生产变更走发布流程 |
| 代码与接口文档 | 代码、接口、部署和示例 | README、API文档和变更说明 | 文档必须与当前版本同步 |
| 代码库理解 | 仓库、入口、依赖和问题 | 模块图、调用链和影响范围 | 敏感代码和密钥不得外泄 |
| 部署与发布辅助 | 环境、配置、流水线和检查项 | 部署脚本草案、检查表和回滚方案 | 生产发布必须审批和可回滚 |
| 研发效能复盘 | 需求、提交、缺陷、构建和交付数据 | 周期、瓶颈和改进实验 | 不以代码量或AI使用量评价个人 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把需求、现有架构、约束和验收标准整理成技术方案、任务拆分和风险。

这一场景的目标是把代码库上下文、接口、规范和测试整理成候选代码和修改说明。

这一场景的目标是把变更、规范、威胁模型和历史问题整理成缺陷、风险、证据和建议。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“代码与接口文档”。它所需输入是代码、接口、部署和示例,目标交付是README、API文档和变更说明。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:文档耗时、测试覆盖变化、代码审查问题命中率。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。