别急着让AI写代码：4个Skills把设计变成可执行任务

为什么设计与规划比写代码更重要

很多AI编程内容都在教你怎么优化Claude Code配置、怎么用最新的智能体框架，或者对比哪个模型最强。但这些技巧并不能帮你开发出更好的软件。一位有20年软件开发经验的工程师在B站分享了他的观点：在智能体开发模式下，真正需要人类专注的是系统设计和任务规划，而不是写代码本身。

软件开发通常分五个阶段：设计、拆解任务、编码、验证、部署。后三个阶段智能体已经能包揽大部分甚至全部工作——它可以提交变更请求，你只需审查。人类早就不再亲自写代码了。如果还在手写提示词或每次接任务都换做法，很难实现规模化。理想状态是：把明确的任务交给智能体，凭借搭建好的流程，智能体随后发起的拉取请求基本直接可用。

验证环节取决于项目类型。开发过拥有数百万用户的关键任务系统的工程师，显然需要更多人工审查和测试；但做业余项目时，他很乐意让智能体做大量代码审查和自动化验证。系统设计这类工作仍需人工介入——不敢完全让智能体评估设计方案。生产环境部署早已自动化，合并代码后系统自动部署。所以开发者真正要专注的是：系统设计（决定做什么、怎么做）、任务拆解、以及根据项目情况做必要的验证把控。

智能体（Agent） 在此语境下指具备自主规划、工具调用与多步执行能力的AI编程助手，如Claude Code、Codex等。与传统代码补全工具不同，智能体可以理解高层任务目标，自行拆解步骤、调用CLI、读写文件并提交拉取请求，人类则退居为设计者与审查者。文章所说的“智能体开发模式”，即把编码、验证、部署等执行环节委托给这类智能体，人类专注系统设计与任务规划。

系统设计的两个阶段

系统设计分两阶段。第一是需求思考：做什么、为什么做、为谁做。第二是技术设计：敲定技术栈、数据库和架构，考虑边界情况、安全、运维指标、监控告警，以及功能在生产环境怎么保障正常运行。技术设计阶段可以让智能体帮大忙。在大公司工作过的人会发现，最资深的工程师大多把时间花在技术设计上，因为这是杠杆效应最高、最需要把控好的核心环节。

视频介绍了四项技能来支撑这个流程：设计技能生成技术设计文档，方便后续拆解任务；架构评审技能找出初始设计中的边界情况、缺陷和错误；HTML文档技能把设计方案转成更优雅的可视化网页；规划技能自动把设计拆解成具体任务。

拉取请求（Pull Request, PR） 是代码协作平台（如GitHub）中提交变更的标准机制：开发者从分支发起PR，请求将改动合并到主分支，并附带变更说明与审查流程。文章提到智能体可以自行发起PR，人类只需审查合并。将设计拆解为任务后，每个任务对应一个或一组PR，便于追踪进度、回滚和代码审查，这也是“任务转PR”技能能够自动串联规划与实现的基础。

architecture.md：全局架构的锚点

无论开发什么项目，都建议准备一个architecture.md文件，记录全局系统的顶层架构。从零开发新项目时，这份文件对自己和参与的智能体都是极佳参考。它侧重顶层系统设计，包含核心组件、数据库选型、API定义（如健康检查端点、工作节点专用独立API）、各项限制细则等。这些细节最容易被忽略——开发者常忘记考虑边界情况、限制条件、管控机制和速率限制。

这些保护机制能真正让软件质量过硬。比如开发SaaS应用却忘了设置限制，客户可能一下子生成上千个资源，造成大笔损失。把限制条件、边界情况和速率限制考虑周全，才能开发出能落地的软件。

实战：给任务管理应用加一个智能体监听功能

演示项目是一个任务管理应用，界面有任务面板、列表、看板视图、表格视图和日历视图。基本思路是把任务加入队列，再让智能体接手完成。要实现这一点，需要让智能体持续监听监控任务看板，自动认领符合条件的任务。

第一步是头脑风暴，理清功能思路，而不是直接写文档。设计是流程中至关重要的一环，需要让智能体充分考虑各种场景和边界情况。所以通常会开启更高阶的推理设置，或直接用目前最强的模型做初步设计，无论Claude还是GPT。

这里有一个关键细节：智能体和你可能有分歧，不必全盘接受它的建议。比如智能体建议通过确定性逻辑自动更新修改后的工单状态，听起来合理，但会引入很多不必要的复杂度。工程师更倾向于直接让智能体去更新，因为如今智能体足够强大，通过CLI工具负责更新任务即可。推进流程时，智能体会做某些决策而你可能并不认同，需要提出质疑或换角度思考，和智能体反复探讨设计决策。

Codex完成了初步设计，生成核心摘要、系统背景、架构示意图和具体设计方案。开发这类功能要花大量时间思考用户体验——实际会运行哪些命令、是否合理、是否符合直觉。设计文档包含大量关键细节，比如智能体可认领任务，但若两个智能体同时争抢同一任务怎么办。这些刁钻的边界情况在初构思时可能没想到，设计阶段正是挖掘潜在问题的好机会。

推理设置（Reasoning Effort） 是部分大模型API提供的参数，用于控制模型在生成回答前进行内部推理的深度。较高的推理设置会让模型花更多时间思考、探索更多可能性，适合系统设计、架构评审等需要周全考虑边界情况的复杂任务；较低设置则响应更快、成本更低，适合编码执行等确定性较强的工作。文章建议在设计阶段开启高阶推理或使用最强模型，正是为了在前期把问题想透。

HTML文档技能与跨模型评审

初步设计文档庞大且详尽，直接通读原稿挺费劲。调用HTML文档技能，可以把设计文档转换成易读的网页版，信息内容完全一致，但排版更直观，还有更清晰的架构图——监控CLI工具负责监听API，另一侧是数据库。对视觉化学习者来说，图表能帮你看清底层实际运行逻辑。

接下来换模型来审视设计：用Codex做的设计，再让Claude通过架构评审技能过一遍，看看能否得出不同结果或反馈。工程师平时不会每次都用第二个模型，但设计阶段调用最强模型多投入Token，长远看反而省钱。若前期出错或落地了错误设计，后面不得不返工填坑，事后纠错代价高昂，不仅多花Token，更现实的是影响用户体验、耽误开发进度。前期把设计做扎实，好过在这个阶段走捷径。

评审设计方案要考虑方方面面：速率限制防止客户在单位时间内发起过多请求；可扩展性——如果只有10个用户跑起来毫无压力，但一上生产环境就崩溃，那是现场编程通病，Demo看着惊艳但无法扩展，说明架构没设计好。

用规划技能拆解任务

让智能体把方案拆解成一系列具体任务并录入问题跟踪系统。强烈建议用智能体来拆解任务——人类并不擅长这类工作，因为它极其复杂、充斥机械繁琐的细节。智能体需要确保所有不变量以及任务条件完整涵盖，人工做非常耗时，智能体对细节的把控强得多。

演示中方案被拆成五个独立任务，清晰概括了任务内容、预期结果、各种约束条件、哪些在范围内哪些不在。确认符合预期后，让智能体创建为GitHub Issue，并关联到同一个母工单下——任务管理器里的工单太多会乱，这些任务都属于同一项工作。任务颗粒度取决于开发需求：如果设计简单，可以全写进一个任务；项目稍复杂、需要边做边测试并在开发流程中不断迭代，拆解成多个小任务就很有用。

最终生成母工单，关联所有子任务，明确交付顺序、验收标准（完成所有子任务）以及部署上线方案。到这步直接交给智能体逐一完成即可。

母工单（Epic） 是问题跟踪系统（如Jira、GitHub Issues）中用于聚合一组相关子任务的工作项。它本身不直接对应一次代码提交，而是定义一个较大的功能目标，并将拆解出的多个子任务关联在其下，统一追踪进度、依赖关系和验收标准。文章演示中将五个子任务关联到同一个母工单，并明确交付顺序与完成标准，使智能体可以按序逐一处理而不丢失全局上下文。

任务转PR：把规划落地为代码

用任务转PR技能，只需把母工单传给它，剩下就是等待智能体按序逐一处理任务。这项技能确保所有改动都经过测试并通过代码审查。至此，从设计、评审、拆解到实现，整条链路都由清晰的文档和可执行任务串起来——人类负责判断和决策，智能体负责机械执行。这正是设计与规划杠杆效应所在：前期多花时间，后期少填坑。