权威消息显示，每天都有新的 MCP、Skill、定制化 Agent 冒出来，社交平台上也不断有人宣称：“这一条 Prompt 让我彻底搞明白了 AI。”现实情况是工具装了一堆，实际效率却没有明显提升。 科技新闻。
这套流程适合边界清楚、结果容易验证、能够快速回滚的任务，例如 UI 组件、独立模块、明确的 Bug 修复和小型重构。
第一版 Date Picker 已经能够运行，但存在动画不一致、文字对比度不足、多余标题和 “Today” 跳转错误等问题。
Co背景与起因
原型可以提前呈现交互、数据流、接口边界和实现约束，减少进入编码后的返工。因此，Burke 提到，多数任务可以使用中等规模模型和中等推理强度；处理同一功能时，尽量保持模型和推理配置稳定，以利用 Prompt Caching。
小编建议无论任务大小，至少保留三项控制：
Burke 在最后还提到，现在没有人掌握唯一正确的 AI Coding 方法。今天流行的 Prompt 和工作流，明天可能就会变成反模式。
Co事件经过
非 UI 任务也可以先做原型。新增 API 端点时，可以让 Agent 通过 Mermaid 图给出多种设计：
人工检查 diff、依赖和配置变化。
对这个 Date Picker 实现进行 Rubber Duck 评审，根据结果完成必要修改，重复执行，直到剩余问题的修改收益已经很低。这类循环可能发现主模型长期忽略的边界问题，但会增加模型调用和 token 消耗。
Co各方回应
用户能否清除日期？
这里需要提醒一下：容器不代表已经完成安全隔离。开启 Allow All 前，仍应检查工作区挂载、开发环境凭据和网络访问范围。Codespaces 中可以配置云服务 Token、SSH Key 等 secrets，运行在其中的命令也可能读取这些变量；端口还可以被转发到组织或公网。
Burke 当时使用的是 GPT-5.6 Terra，Copilot 为评审调用了 Sonnet。不同模型可能存在不同盲区，第二次评审有机会发现主模型遗漏的问题。Rubber Duck 也可以用于检查原型和计划，不必等到实现全部完成。
Co影响分析
Plan mode 会继续询问需求边界：
其中一个方案从年份视图开始，这让他确定了最终交互方向：先看年，再进入月和日。多个低成本原型并排展示，比单纯讨论需求更容易发现不同方案的差异。
是否允许手动输入和粘贴？
Burke 没有直接实现 Date Picker，而是先让 Copilot 生成 20 个原型：
这些问题很难在第一条 Prompt 里一次写全。模型负责补充问题，而用户则负责做出取舍。如果你需要更深入的追问时，可以安装 Matt Pocock 的 grill-me skill。不过，问题问得多不代表计划更合理。用户仍要确认哪些边界真实存在，并要求模型解释含义不清的概念。
用户不需要提前配置定制化 Agent，也能使用这些内置能力。Burke 是将其视为 Harness 已经封装好的一部分。
日期以什么格式保存？
这里也需要提醒一下，Burke 在原文中没有展示测试、类型检查、Lint 和 Build。如果你在用于生产项目时，提交前还应运行项目已有的检查，并人工查看最终 diff、依赖变化、异常处理和配置修改。
在 GitHub 负责 AI-powered development 的 Burke Holland 建议，先别急着学完所有 AI 工具，选一个成熟的 Agent Harness，通过真实任务把 AI 用明白。
当计划确认后，你可以切换到 Autopilot。Autopilot 会持续读取代码、修改文件和运行命令，直到任务完成、遇到阻塞、被人工中止，或者达到最大续跑次数。
Burke 建议新手从 GitHub Copilot CLI 起步。终端界面以文本交互为主，用户可以直接观察 Agent 如何读取文件、调用工具和执行命令。
团队使用时，还要解决 Agent 产出如何进入 Code Review、共享配置由谁维护、变更如何审计，以及出现问题后如何回滚。Burke 展示的是个人工作流，没有展开这些问题。
Copilot CLI 支持 --allow-all、--yolo，交互会话中也可以使用 /allow-all 或 /yolo。GitHub 官方建议只在隔离环境中使用这些全权限选项。
完成多轮修改后，Burke 建议请求 Rubber Duck review。
Burke 在第 2 步提到会放开 Agent 的执行权限，而第 6 步又要求严格检查产出，其实这两者并不冲突。Allow All 省掉的是反复点击批准，质量和风险控制则分散在自然环境隔离、计划确认、人工迭代、测试、diff 检查和模型评审等环节。只放开权限，不补上这些控制点，风险也会随执行效率一起增加。
Copilot CLI 中，每条消息、模型回复、工具调用及其成果都会占用上下文窗口，可以通过 /context 查看用量，通过 /compact 压缩当前会话。
GitHub Copilot 有 CLI、Copilot app、VS Code、Visual Studio 和 JetBrains 等入口。界面各不相同，但核心流程逐渐收敛到同一套 harness。实际使用中可以先用一个工具完成一个任务，再考虑切换入口。
Harness，可以理解为支撑 Agent 运行的一整套控制层，包括上下文管理、工具调用、任务编排和权限控制。GitHub Copilot 是 Burke 用来演示的具体产品，原文为了简化表述，将 Copilot 与 Harness 交替使用。
社区通常将这类跳过逐次确认的模式称为 YOLO，在 GitHub Copilot CLI 中对应 Allow All。开启后，Agent 使用工具、访问路径和执行命令时，不再逐次等待人工批准。
模型已经掌握当前代码和上下文，用户只需说明问题和期望结果。后续要求也很具体：删除多余标题、修正悬停可读性、让 Today 正确跳转，以及简化月份和年份的展示。
不可逆的数据操作，身份、支付、安全和合规代码，生产环境与基础设施变更，以及缺少测试和明确 owner 的代码库，需要更严格的权限、审批和分阶段执行。全权限模式本身也只适合目标清楚、权限受控且能够回滚的任务。
“两个模型都以为可以停止”只是主观标准。实际任务还应检查验收条件、测试结局、高风险问题、变更范围和最大循环次数。
在完成原型、规划、实现和评审后，就可以暂存、提交代码，或者继续处理当前 Pull Request 中的相关修改。
这一步的标准很明确：不能把“已经运行”当成“已经完成”。最终产出的质量，仍然取决于用户能否发现问题并持续修改。
不过，这套八步流程提供了一条清楚的实践路径：
你可以在交互会话中可以通过按 Shift+Tab 切换至 Autopilot；程序化执行时可以使用 --autopilot，并通过 --max-autopilot-continues 限制续跑次数。
Burke 还将 Rubber Duck 与 Autopilot 组合成循环：
方向确定后，Burke 在当前会话中切换到 plan mode：
要注意 Rubber Duck 属于模型评审，不能替代测试、CI 和人类 code review。
如果每读取一个文件、运行一条命令都要点击确认，那么，用户仍然是要守在电脑前。连续审批还容易变成机械操作，人最终不会认真检查自己批准了什么。
Autopilot 与 /delegate 是两套机制。Autopilot 在本地 CLI 会话中运行；/delegate 会把任务交给 Copilot Coding Agent，由后者在远程创建分支和 Draft Pull Request，并在后台继续干活。
Burke 建议，与当前任务无关的劳动新开会话。一次会话最好围绕同一主题展开；任务明显偏离当前主线时，旧上下文会继续占用有限的上下文窗口，也可能增加 token 和用量消耗。仍在处理同一功能时可以保留会话，开始无关任务时则重新建立上下文。
是否允许只完成部分选择？
更稳妥的做法是让 Agent 在临时分支或 worktree 上工作，不提供生产凭据，并保证变更可回滚。Copilot CLI 也支持用 allowlist 和 denylist 细分权限，例如允许 git commit，同时禁止 git push。
这里需要注意模型的切换，或者在会话中修改 Reasoning Effort、Context Size、启用的工具和 MCP server，都可能使缓存失效。长时间离开旧会话后，缓存也可能过期。具体策略取决于 Copilot 或和你选用的其他 Agent 以及底层模型。
Burke 建议不要直接在存有工作资料的本地环境中开启 Allow All，可以使用 GitHub Codespaces、Development Container 或其他沙箱。
对同时运行多个 Agent 的人来说，主题清晰的会话也更容易追踪每个任务已经做到哪一步。
因此，他建议先选定一个 AI 工具，把完整干活流跑通。本文以 Date Picker 组件为例，梳理这套从原型、规划、实现到评审的八步流程。下面咱们就一起看看他是怎么做的：
Rubber Duck 是 GitHub Copilot 内置的评审 Agent，它会检查当前计划、代码或测试，并给出第二意见。在存在合适评审模型时，Rubber Duck 会使用不同于主会话的模型。
起止日期能否相同？
复杂项目也可以沿用相同思路，但原型形式需要变化。面对遗留系统、跨服务修改或数据库迁移，原型可以是调用链、API Contract、Schema 方案、迁移与回滚路径，或者一次小范围 Spike。
点击“日”时，组件还在尝试继续放大，但已经没有更细的层级，这里不应再触发缩放。
先做原型，确认方向； 再用 plan mode 补齐边界； 让 Autopilot 执行计划； 人工迭代并运行工程检查； 最后用 Rubber Duck 补充评审。
提交前运行测试、Lint、类型检查和 Build；
在此过程中，Copilot 会承担一部分编排工作。探索代码库时可能调用 Explore 子 Agent，处理复杂的多步骤任务时也可能使用 General-purpose 子 Agent。具体是否委派、委派给哪个 Agent，由主 Agent 根据任务判断。
“今天”是否始终显示？
Burke 随后补充设计约束，并直接用自然语言列出问题。他将自己创建的 Postrboard CSS 框架封装成 Skill，为 Agent 提供视觉规则。针对具体交互，他的 Prompt 很口语化：
Burke 并不否定 MCP、Skill、Instructions 和定制化 Agent，复杂工作流和团队自动化仍然需要这些扩展能力，他在演示中也用到了 Skill，但它们不是开始使用 AI 的前提。当前生态里还有大量未经验证的 Slop，Agent 很快就能生成一个 Skill，能不能用却是另一回事。
动手前确认验收标准和修改范围；
你可以先用一套工具稳定完成任务，再根据实际需求加入 MCP、Skill、Instructions 和定制化 Agent。工具越多，配置和维护成本也越高。当前，如何让 AI 重复产出可靠结果，比追上每个新功能更重要。