在真实上下文中工作。
授权一个工作区，提出明确的修改要求。范围不清楚时，可以先做只读分析。
看一个任务怎么完成
从一句要求，到通过验证的改动。
六个阶段，全程看得见：理解、计划、实现、验证、审查、交付。
要求修复 src/price.js：折扣结果四舍五入到整分，价格始终显示两位小数；改完运行 npm test。
- 理解
- 计划
- 实现
- 验证
- 审查
- 交付
计划
- 找到折扣计算和价格格式化的位置
- 折扣结果四舍五入到整分
- 价格始终显示两位小数
- 跑测试确认通过
src/price.js +2 −2
export function applyDiscount(cents, percent) { - return Math.floor(cents * (100 - percent) / 100); + return Math.round(cents * (100 - percent) / 100); } export function formatPrice(cents) { - return `¥${cents / 100}`; + return `¥${(cents / 100).toFixed(2)}`;
验证
- 类型与静态检查0.8s
- 相关测试6 / 6
- 全量测试48 / 48
- 构建2.1s
已完成并验证
改了什么折扣改为四舍五入；价格格式固定两位小数。
怎么验证的静态检查、相关测试 6/6、全量测试 48/48、构建通过。
还有什么风险其他货币的格式没有覆盖。
开 PR →示意动画：按 TheOne 编程任务的真实阶段和界面重现，不是实时运行。
软件工程工作流
探索、修改、检查、审查。
跟随每一步执行。
查看运行时报告的计划、工具活动、文件修改和检查。直接看到问题，而不是猜测进展。
交付之前，先审查。
依据 Diff、测试结果和执行记录判断改动。PR 交付需要相应的运行环境与授权。
编程实例
可以这样交给它。
修一个 bug，不改测试
“测试里有一个失败的用例，找到原因并修复实现，不要改测试。”
- 读失败的测试和相关代码，定位原因
- 只改实现，测试文件保持不动
- 跑相关测试和全量测试
你拿到通过验证的改动，以及一句话讲清原因。
读懂一个陌生的代码库
“分析这个代码库的结构和主要风险，给出 3 条最值得先做的改进。”
- 只读分析，不改任何文件
- 梳理模块、依赖和风险点
- 报告里的每条建议都能一键执行
你拿到一份可以直接照着做的分析报告。
升级依赖
“把 next 升级到最新的补丁版本，跑完测试和构建。”
- 读更新说明，找出破坏性变更
- 升级并修好受影响的代码
- 全量测试和构建都要通过
你拿到一个开好的 PR，风险写在说明里。
加一个功能，顺手补测试
“给导出功能加上 CSV 格式，并补上测试。”
- 先列计划，按步骤实现
- 为新功能编写测试
- 界面改动附前后截图
你拿到功能、测试和截图，一起交付。
编程能力
14 个工程技能，六层验证。
TheOne 根据你的要求自动选用技能；检查一直跑到改动被证明可用，或者明确指出还差什么。
工程技能
代码审查修复缺陷功能开发发布上线线上故障处理安全审查重构编写测试接口设计数据库变更性能优化依赖升级技术文档架构设计
验证分层
- 1类型与静态检查
- 2相关测试
- 3全量测试
- 4构建
- 5端到端
- 6视觉回归
在哪里工作
- 通过桌面版，直接改你电脑上的文件夹和仓库
- GitHub 仓库，并为你开 PR
- 通过自动化，由 GitHub 事件触发
怎么交付
- PR 写清改了什么、为什么、怎么验证的、还有什么风险
- 界面改动附前后对比截图
- 说“继续”就接着同一个任务和工作区
多种引擎，同一工作流。
选择合适的智能。
无论哪个引擎执行任务，你看到的都是同样的计划、实时进度、检查和结果卡。
原生 Agent 循环，负责仓库探索、编辑、工具调用和检查。
配置好的 Codex 执行路径，结果呈现在同一个任务工作区。
配置好的 Claude 编程引擎，遵循相应运行时和服务商要求。
可用的引擎取决于你的套餐和工作区配置的凭据。
更诚实地定义“完成”
证据比宣称更重要。
看似合理的回答不等于测试通过。测试通过，也不保证所有需求都已满足。
检查实际改动
查看 Diff 和受到影响的工作区。
检查验证范围
查看实际检查及其结果。独立验证是另外的工作流状态。
保持发布权限独立
审查候选改动，并遵守代码库已有的审批和发布流程。