ArchPilot 架构领航

01 / CONTEXT

背景

编码工具让“写出第一版代码”变得很快，但它不会自动补上需求边界、模块职责和验收标准。很多项目从一句模糊的想法直接开写，几轮迭代后才发现最早的问题是没有先把第一步想清楚。

ArchPilot 想补上的正是这段空白：在开始写代码前，用一种新手也能跟上的方式，把想做什么、先做什么、哪些暂时不做说清楚。

02 / CHALLENGE

挑战

如果一口气抛出几十个架构问题，新手还是不知道怎么选；如果工具代替用户决定一切，输出又会变成不透明、难以维护的黑箱。它既要保持引导性，又要让每一个决定有迹可循。

另一个常见问题是过度设计。一个小型应用不应该因为“看起来专业”就默认被拆成微服务、消息队列和复杂权限系统，合适的复杂度本身就是设计的一部分。

03 / ARCHITECTURE

方案与选型

Skill 把流程分成需求翻译、架构设计和开发执行三层。交互一次只推进一个关键问题，在关键节点生成确认稿；确认后的内容再进入模块拆分和阶段计划，而不是让需求在对话里悄悄漂移。

最终输出固定为一份可执行的开发设计包。每个核心模块都会说明负责什么、不负责什么、输入输出、依赖、隐藏细节、扩展点与测试重点，让后续编码时有可检查的边界。

04 / REAL_EFFECT

实际效果

例如输入“我想做一个 AI 简历改写工具”，它不会马上给出一堆文件。流程会先确认目标用户、界面语言、资料输入、结果结构、是否保存数据、真实服务配置、部署位置和开发者当前水平。

确认之后，原本的一句话会变成结构化需求确认稿、模块设计和接口契约、后续功能的变更影响说明，以及能够分段交给编码工具的提示词。每一步都有需要运行的检查，而不以写一段假结果作为结束。

Skill 也明确要求区分真实结果与 Mock，并先定义可复用的颜色、间距、圆角和动效 token，再把这些约束带入后续前端实现。

05 / CURRENT_STATE

当前状态

仓库公开提供安装和使用说明、场景示例、确认稿与开发包模板、复杂度评估、模块契约、变更影响规则以及 Python 校验脚本。它更像一个可复用的项目启动方式，而不是一次性的提示词集合。

截至 2026-09-08，GitHub 仓库有 47 个 Star、1 个 Fork。收藏数据会变化，所以这里标记核验日期；更重要的是，它已经可以被下载、安装并直接用于新项目规划。