企业官网建设流程全解析

• 前端
• UI组件

本文基于 Motion（React/JavaScript 动画库）monorepo 中.agents/skills/improve工作流所用的审计手册（audit-playbook），结合仓库内真实审计产出（plans/README.md、plans/PERFORMANCE_AUDIT.md及各编号计划文件）展开，讲解一套"以证据为中心的九大类代码审计方法论 + 统一发现格式 + 杠杆率优先排序"的完整实践路径。读完本文，你将掌握如何对一个大型 monorepo（如 Motion 这种含motion、framer-motion、motion-dom、motion-utils多包结构）进行分层审计，并输出可供其他模型直接执行、可验证、零上下文依赖的改进计划。

导读

Motion 仓库的.agents/skills/improve技能定义了一个完整的"顾问式审计工作流"：先 Recon 摸清仓库，再按九个类别并行审计，逐条产出带证据的发现，最终按杠杆率排序并写成自包含实现计划。其核心方法论沉淀在 audit-playbook.md 中——本文以它为骨架，逐类别讲解"该看什么、证据长什么样、如何避免误报"，并对照仓库真实审计结果（如 plans/README.md 中 38 个计划的生成记录、PERFORMANCE_AUDIT.md 中 47 条带 file:line 引用的性能发现）验证每个方法论要点，最后给出可直接套用的"发现格式 + 优先级排序 + 计划模板"实战模板。

一、Playbook 的定位与"证据优先"原则

audit-playbook 开篇就定义了整份手册的纪律：

"A finding is only a finding with evidence. 'Probably has N+1 queries somewhere' is not a finding;orders/api.ts:142 issues one query per order item inside a loopis."

没有证据的发现不是发现。这一点在 Motion 仓库的审计实践中被严格贯彻：PERFORMANCE_AUDIT.md的 47 条发现全部附带file:line引用，例如：

• "Transform shorthands（x/scale/rotate）留在 JS 主线程" 这条 HIGH 影响度发现，机制列写明acceleratedValues缺少 shorthands、name="x"走 JSAnimation 导致每帧重建样式；
• "Box-shadow 投影缩放校正双重解析" 指出correctBoxShadow在complex.parse+complex.createTransformer中对每个元素每帧执行两次analyseComplexValue（值系统中最重的字符串操作）。

手册还要求按仓库规模调整审计深度：2K 行的 CLI 项目做轻量审计，500K 行的 monorepo（Motion 正是后者的量级——仅packages/motion-dom/src就有 animation、effects、frameloop、gestures、projection、render、value、view 等十余个模块）则必须分片并行审计。

1.1 与 improve 技能工作流的衔接

audit-playbook 是 SKILL.md 定义的"顾问（advisor）而非实现者（implementer）"流程的第二阶段工具：

1. Phase 1 — Recon：读README、AGENTS.md、根配置（package.json），摸清构建/测试/lint/typecheck 的确切命令；
2. Phase 2 — Audit：按 playbook 的九大类别并行审计（可派 Explore 子代理，每个子代理必须携带 playbook 绝对路径 + "## Finding format" 章节）；
3. Phase 3 — Vet：对子代理产出的每条发现亲自打开源码复验——playbook 与 SKILL.md 都强调子代理会过度报告，存在"by-design 行为被报成 bug""证据张冠李戴""跨类别重复"三类失败模式；
4. Phase 4 — Write the plans：按 plan-template.md 为选中的发现写零上下文自包含计划。

仓库中plans/README.md记录了这套流程的真实产出：2026-06-10 的/improve next方向审计、06-11 的/improve deep九类全量审计、以及针对 Reorder、drag、frameloop、spring、bundle-size 的多次聚焦审计，共生成 38 个编号计划。其中连"编号冲突如何裁决"（011/012 撞号、022 三连撞）都有详细仲裁记录，说明这是被真实高频使用的生产级工作流。

二、九大审计类别逐项拆解

playbook 将审计分为九个类别，按信任度与默认优先级排列。以下逐类说明"看什么"，并给出仓库内的真实例证。

2.1 Correctness / Bugs——最高信任度类别

"真正通过阅读代码发现的 bug，而非猜测。"核查清单包括：

• 错误处理：被吞掉的异常、空 catch 块、关键路径上catch (e) { console.log(e) }、UI 代码缺失错误态；
• 异步隐患：未 await 的 Promise、共享状态上的竞态、缺少取消/清理（React effect 中的陈旧闭包、未移除的监听器）；
• 空值/undefined 流程：对可能为 null 的值用非空断言!、用可选链掩盖"必须存在"的值、无检查的数组索引；
• 边界条件：off-by-one、空集合处理、时区/locale 假设、计数器/ID 的整数溢出；
• 状态机：类型中可表示的非法状态组合、状态枚举存在未处理分支（警惕静默 no-op 的default:）；
• 并发：共享资源上的 check-then-act、多写操作缺事务、重试操作（webhooks、队列）的幂等性；
• 类型逃生舱：any/as断言 /@ts-ignore聚集处——每一处都是编译器被否决的地方；
• 资源泄漏：未关闭的句柄、连接、订阅；缺失finally。

仓库实践对照：plans/README.md记录了 spring 审计对"restSpeed: 0/restDelta: 0静默回退到默认值"的裁定——spring.ts:275-280的||=是防御性设计（restDelta: 0要求浮点严格相等，弹簧将永不收敛），因此判定为"按设计工作"，列入拒绝清单而非发现。这正是正确性审计的典型判断：需要区分真 bug 与故意行为。

2.2 Security——只报告代码中有证据的内容

playbook 对安全审计有两条铁律：

1. 禁止在发现或计划中复制秘密值——这些文件会被提交。只引用file:line和凭据类型（如 "Stripe live key atconfig.ts:12"），且修复草图必须包含轮换（rotation）而非仅删除，因为已提交的秘密即使删除也已失效；
2. "按设计"不是发现——遵循https_proxy/NO_PROXY、读取~/.netrc、本地开发工具调用配置的包管理器等平台惯例是故意行为，仅当实现在惯例之外增加了风险时才标记。

检查面包括：硬编码密钥/令牌/密码、提交的.env、日志或事件存储中的秘密；字符串拼接的 SQL/shell 命令、dangerouslySetInnerHTML/innerHTML接用户数据、动态输入的eval/Function、用户文件名的路径穿越；缺失鉴权的端点、仅客户端鉴权、IDOR、状态变更路由缺 CSRF；API 边界信任请求体（无 schema 校验）、文件上传处理、请求对象的大批量赋值；依赖审计（只读模式跑npm audit等，标记有已知漏洞的 critical/high 项）；CORS 通配符带凭据、缺失 CSP、无HttpOnly/Secure/SameSite的 cookie、生产配置可达的 debug 模式；日志中的 PII、返回给客户端的堆栈跟踪、API 响应中的内部错误细节。

仓库实践对照：plans/README.md显示计划 006 曾涉及"轮换暴露的UPDATE_SECRET_TOKEN+ 秘密扫描 CI 门禁"，且该计划在 2026-06-22 被删除时特别标注：第 0 步（轮换暴露的令牌）是独立于 CI 门禁的人类动作，删除计划不代表令牌已解除暴露，需单独处理——与 playbook"秘密一经提交即烧毁，修复必须轮换"的原则完全一致。

2.3 Performance——找算法与架构级收益，而非微优化

• N+1 模式：循环内或按列表行渲染逐项查询/请求；缺批处理或 dataloader；
• 错误复杂度：对同一集合的嵌套扫描、热循环内重复find/filter（应改用 Map 键查找）；
• 缓存缺口：每次请求/渲染重复的昂贵计算或请求；清晰函数边界处缺 memoization；
• 载荷大小：过度抓取（select *）、无分页的无界列表、发给客户端的大 JSON；
• 前端：bundle 构成（大依赖干小事）、罕见路由缺代码分割、未优化图片/字体、渲染瀑布流；
• 后端：应入队列的同步工作、查询模式暗示缺索引（需 schema 证据，不可臆断）；
• 构建/CI：缺缓存导致的慢 CI、冗余流水线步骤、可并行化的测试套件。

仓库实践对照：PERFORMANCE_AUDIT.md是这条方法论的最佳范本。其 Top-5 高杠杆发现包括：为x/scale/rotate简写拓宽 WAAPI 加速资格（最常见动画场景脱离主线程）、在linear()存在后重新启用 background-color/color 的 WAAPI 加速、will-change在动画完成时未重置回auto、box-shadow 缩放校正单次解析、以及让 styleEffect 成为非投影元素的默认渲染路径。更重要的是它先证伪了一个民间神话：通过逐行核验render.ts:13-25（纯写入，零布局读取）和 frameloop 的"读先于写"结构（batcher.ts:60read 步骤先于:65render 步骤），证明"每帧写全部样式"的成本是冗余 JS 工作与冗余 CSSOM setter 调用，而非 N 次重排——真正杠杆是"只写变更的键"，即 effects 路径的做法（effects/style/index.ts:55-59，每个键一个闭包，仅在该键变更时调度）。这种"先验证问题是否真的存在，再谈优化"正是 playbook 的深层精神。

2.4 Test Coverage——目标不是覆盖率百分比，而是"哪些未测代码危险"

• 绘制关键路径图（金钱、鉴权、数据变更、仓库存在的意义所在功能），检查哪些为零覆盖或琐碎覆盖；
• 高变更率模块（git log）+ 无测试 = 重构风险最高，标记为"先写特征化测试（characterization tests）"候选；
• 现有测试质量：断言无意义、重 mock 到"测的是 mock"、无人看的快照测试、易碎模式（真实定时器、真实网络、顺序依赖）；
• 缺失的测试层：仅单元测试、API 边界零集成覆盖，或反过来的"本可用单元测试捕获却写慢速 E2E"；
• 验证基础设施：是否存在一条命令就能确认代码库可用？如果没有，这本身就是发现 #1，也是任何高风险变更的前置计划。

仓库实践对照：plans/README.md中计划 009（LayoutAnimationBuilder特征化测试）与 007（lint 门禁）、010（清理死 devDependencies）、025（resize 单元测试 + 接线死掉的 ResizeObserver mock）、029（frameloop 测试缺口补全）都直接来自这一类别。依赖图部分明确写道："009 应早于任何对LayoutAnimationBuilder.ts的重构落地——它存在的意义就是让这类变更变得有意识。"这正是"特征化测试先行"原则的执行证据。

2.5 Tech Debt & Architecture

• 重复：同一逻辑在 3+ 处重新实现（搜索近似相同函数/组件）；发生漂移的分叉副本；
• 分层违规：UI 导入数据层内部、循环依赖、"utils" 变成高扇入的杂物抽屉；
• 死代码：未导出且未使用的模块、已完全上线却仍在分支的功能开关、无说明的注释块、清单中不再被导入的依赖；
• 上帝对象/模块：比仓库中位数大一个数量级且人人都在碰的文件；双位数参数或深层条件嵌套的函数；
• 不一致模式：同一仓库三种数据获取/错误处理/样式写法——选定赢家（团队最近收敛的那个）并规划整合；
• 抽象错配：只有一个实现的过早抽象，或缺少抽象导致同一变更总需锁步改 N 个文件。

仓库实践对照：plans/README.md的"Rejected"部分完整记录了这一类别的否决清单，包括：create-projection-node.ts上帝模块（2,465 行，仓库中位数 91 倍）——真实债务，但当前与进行中的 effects/VisualElement 统一化冲突，此时拆分属于浪费；defaultEasing的splicevsslice（animation/generators/keyframes.ts:21）——变异临时数组被丢弃，不地道但不是 bug；"styleEffect 渲染路径已上线"——实际上80d85dbeb提交只存在于worktree-style-effect分支而非 main。这些记录的价值在于：被否决的发现被永久归档，避免下次审计重复劳动——这也是 playbook 与plans/README.md索引中"Findings considered and rejected"章节存在的意义。

2.6 Dependencies & Migrations

• 核心框架/运行时的重大版本滞后（不是每个 minor——是真正有落后成本的那些：EOL、安全修复截止、生态不兼容）；
• 使用已宣布移除时间线的弃用 API；
• 关键路径上的废弃依赖（多年无发布、仓库已归档）；
• 解决同一问题的重复依赖（两个日期库、两个 HTTP 客户端）；
• lockfile/清单漂移、monorepo 内的版本固定不一致；
• 每个迁移候选都要估算爆炸半径（触及文件数）——它决定工作量与是否值得推荐。

仓库实践对照：plans/README.md的"审计发现暂缓"列表列出 Motion 的真实迁移滞后：lerna 4→8、turbo 1→2（含低危公告 GHSA-3qcw-2rhx-2726）、cypress 4→当前、prettier 2→3、eslint 8→9 flat config、TS 5.4→5.8、@types/node 18→20 及发布包缺engines字段——并注明"全部触及发布流水线，各自需要一份 opt-in 计划"。这正是"爆炸半径驱动工作量与是否推荐"的实践。

2.7 DX & Tooling

• 缺失或损坏：typecheck 脚本、lint 配置、格式化器、pre-commit 钩子、editorconfig；
• 慢反馈回路：dev-server 或测试启动以分钟计、无 watch 模式、CI 无缓存；
• 上手摩擦：README 设置步骤错误/不完整、未记录的必需环境变量、无.env.example；
• 缺失CLAUDE.md/AGENTS.md——对于将由 Agent 执行计划的仓库，这是高杠杆项：推荐补一个并把提纲写进计划；
• 错误消息/日志：服务日志无结构、缺请求 ID/关联、调试需改代码。

仓库实践对照：计划 007（"lint motion-dom/motion-utils + 阻塞性 CI lint 任务"）直接命中"缺失 lint 门禁"；plans/README.md还记录了"仓库级 typecheck（含 tests/dev apps）缺失——两个包 tsconfig 都排除了__tests__，任何地方都没有 typecheck 脚本"这一真实 DX 缺口。而 Motion 仓库自身就维护了 AGENTS.md（定义 monorepo 结构、三种测试套件的运行方式）与 CLAUDE.md（含"优先小文件体积"等编码原则），为 Agent 执行提供了基线。

2.8 Docs——默认最低优先级，仅在缺失有具体代价时标记

• 公开 API 面（已发布包）无参考文档；
• 无人能重建的架构决策（为什么选 X 不选 Y），针对正在激烈争论的领域；
• 过时且活跃错误的文档（比缺失更糟）——设置说明、不再编译的 API 示例。

仓库实践对照：plans/README.md明确将"motion-dom 公共 API 文档缺失（无包 README；LayoutAnimationBuilder、arc()除源码外无文档）"列为真实但低于计划门槛的发现，部分由计划 001 的文档要求覆盖——并注明"motion.dev 文档在本仓库之外，不属于此处的计划范围"。

2.9 Direction——未来走向，但每条建议必须有仓库自身证据

这是唯一面向未来的类别，playbook 给出了严格的接地规则："每条建议必须引用仓库自身的证据——一条可套用到该类目任何项目的建议（'加暗色模式'、'加 AI'）是噪音，不是发现。"证据来源：

• 未完成的意图：围绕同一主题的 TODO/FIXME 聚集、从未上线的功能开关、半建成的模块、被注释掉的特性代码、git 历史中可见的中途废弃；
• 说了但没交付：README/文档/路线图承诺但无对应代码、无效的 CLI 标志或配置项、为不存在功能准备的 issue 模板；
• 表面不对称：单向对（有 export 无 import、有 create 无 bulk-create、webhook 只出不进）、CRUD 少一角、内部代码显然需要并手写绕过的公共 API；
• 相邻可能：现有架构让某能力异常廉价——只隔一个接口的插件系统、距现有服务层只差一个路由文件的公共 API、数据模型已支持的集成；
• 值得产品化的摩擦：项目用户明显在手动做的事（文档、示例、issue 中可见）而项目可吸收。

方向发现使用标准格式，但有两个调整：Impact是产品/用户价值（谁想要、为何现在），Confidence反映证据的扎实程度而非"这是否正确"；努力度估算更粗略，须明说；选中的方向发现通常写设计/验证型计划（调研、原型、定义 API、列出开放问题）而非"全量构建"计划。

仓库实践对照：plans/README.md的方向审计产出包括：计划 001"将animateLayout()提升为 motion-dom 公共 API"（P1/S，几乎免费且弥合最大平价缺口）、计划 005"基于网格/距离的stagger()"、计划 002"完成animateView()非根目标解析"。plans/README.md中 012 号设计验证计划则典型体现了"设计/验证而非全量构建"：它产出的是设计文档而非代码——统一 MotionValue 派生机制（eager push 的subscribeValue与半成品的dependents/dirty()信号图），并明确写出约束："该库面向终端用户、bundle size 是硬优先级（见CLAUDE.md'Prioritise small file size'）——设计空间是'最小脏标志 + 帧边界 flush'，而非移植 Reactively。"

三、统一发现格式：每条发现都必须长这样

playbook 规定：来自每个类别、每个子代理的每条发现，都必须以统一格式返回：

### [CATEGORY-NN] 简短祈使句标题 - **Evidence（证据）**: `path/file.ts:123` — 一句说明此处有什么。（每处重复一次；2–5 个最强位置，若普遍存在则注明 "and ~N similar sites"） - **Impact（影响）**: 会出什么问题 / 为此付出什么。要具体："每次订单列表渲染发出 1+N 查询"，而非"次优"。 - **Effort（努力度）**: S（数小时）/ M（约一天）/ L（多天）——针对*修复*本身，含测试。 - **Risk（风险）**: 修复可能破坏什么；LOW/MED/HIGH + 一句理由。 - **Confidence（置信度）**: HIGH（读了代码，确定）/ MED（强信号，需验证）/ LOW（气味，需调查）。LOW 置信度发现可以报告，但配的是"调查"计划而非"修复"计划。 - **Fix sketch（修复草图）**: 1–3 句。不是完整计划——只够诚实评估工作量。

这套格式的每个字段都在为后续决策服务：Evidence让子代理的发现可被复验（Phase 3 的 Vet 环节会亲自打开每个引用）；Impact的具体性保证"杠杆率排序"（impact ÷ effort）有实义；Confidence决定计划类型（LOW 只配 investigate 计划）；Fix sketch让排序阶段的努力度估算有据可依。

四、优先级排序法则：杠杆率 = 影响 ÷ 努力度

排序公式为leverage = impact ÷ effort，再以置信度与修复风险折现。平局裁定顺序：

1. 任何能解锁其他发现的事项（验证基线、特征化测试）上浮；
2. HIGH 置信度的安全发现，浮在同等杠杆的非安全发现之上；
3. 优先选择修复有干净验证故事的发现——执行者模型在这些事上成功率最高；
4. "不值得做"是合法裁决——记录一行理由，让用户知道它被考虑过。

仓库实践对照：plans/README.md的执行顺序表正是这套法则的产物：P1 项包括计划 007（lint 门禁）、019（拖拽/平移手势引擎迁往 motion-dom）、022（press 结束事件过滤修复）、023（键盘 press 监听器生命周期）、027（frameloop 异常恢复）、030/031（spring 视觉时长与过阻尼弹簧修复）、035（bundle 预算成为阻塞门禁）；而多个"不值得做"裁决也被如实记录，例如："PanSession.startScrollTracking每次拖拽开始遍历所有祖先执行getComputedStyle——每次手势一次而非每帧一次，可忽略，不值得缓存"、"resize()观察 content-box 却报告 border-box——真实不一致，但改变观察盒型会改变所有现有消费者的回调时机，且无损坏报告，仅在用户报告时才修复"。

五、审计深度的三级配置：quick / standard / deep

playbook 要求按努力等级调节审计深度（用户可在调用中写quick或deep关键词），SKILL.md 给出完整对照表：

无论何种等级，最终报告都必须说明哪些内容未被审计。大型 monorepo 即使deep也把子代理限定在包级别而非根级别。Motion 仓库的真实实践正是如此：2026-06-11 的/improve deep全量审计与多次聚焦审计（security、perf、tests、Reorder、spring、bundle-size）产生了 38 个计划，而 spring 审计发现的 032 号计划（spring 动画 polygon 点 NaN，#2791）按仓库政策硬性要求先复现——"无复现 → 不修复"，这是对"HIGH 置信度才配修复计划"原则的严格化。

六、把发现变成可执行计划：plan-template 与 plans/ 索引

audit-playbook 的终点是 plan-template.md 定义的零上下文交接计划——写给"从未见过本次对话、代码库勘察或任何其他计划"的执行者模型（可能更小更便宜）。三个属性决定一份计划能否被较弱模型执行：

1. 自包含上下文——所需一切都在文件里：路径、代码摘录、约定、命令；
2. 验证门禁——每一步都以"命令 + 预期结果"结尾，执行者永远不必判断是否成功；
3. 硬边界与逃生舱——显式的 out-of-scope 清单，以及"当现实与计划不符时 STOP 并报告"的条件，而非让模型即兴发挥。

计划文件结构包括：Status 块（Priority/Effort/Risk/Depends on/Category/Planned at 提交 SHA/Issue）、Why this matters（2–5 句，让执行者与人类评审者理解意图）、Current state（内联代码摘录 + 仓库约定 + 一个示例文件指针）、Commands you will need（命令表格，Recon 期间验证过而非猜测）、Scope（in-scope / out-of-scope 显式清单）、Steps（每步小到可独立验证，按"代码库步骤间永不被破坏"排序）、Test plan、Done criteria（可机器检查、全部必须成立，如"pnpm typecheck退出 0""grep -rn "<旧模式>" src/无匹配""无 in-scope 清单外文件被修改"）、STOP conditions、Maintenance notes。

同时，所有计划写入plans/目录并配套plans/README.md索引（执行顺序、依赖图、状态列——状态值 TODO | IN PROGRESS | DONE | BLOCKED（附一行原因）| REJECTED（附一行理由））。SKILL.md 还要求：写计划前先记录git rev-parse --short HEAD（每份计划盖章其撰写时的提交，执行者用它做漂移检测）；若plans/已有历史产出则调和而非重复（保持编号单调、跳过已计划或已拒绝项、标记过时计划）。

七、复盘闭环：execute / reconcile / --issues

audit-playbook 配套的 closing-the-loop.md 定义了三段后续流程：

• execute <plan>：派发独立的执行者子代理（隔离 git worktree）实施计划，顾问像技术主管一样评审 diff——重跑每条 done 标准、检查范围合规（scope 外任何文件即评审失败）、通读完整 diff、审计新测试是否真的断言了有意义的东西。裁决为 APPROVE / REVISE（最多两轮）/ BLOCK；
• reconcile：处理上次会话以来的变化：验证 DONE 计划、调查 BLOCKED 原因、刷新漂移的 TODO、退役死发现；
• --issues（显式授权标志）：把每份计划以gh issue create --title "<计划标题>" --body-file <计划文件>发布为 GitHub issue，标签improve+ 类别。

这一闭环让审计不只是"一份报告"，而是一个可持续运转的改进循环——plans/README.md中"计划文件是唯一事实源，issue 只是分发渠道；自包含规则在此兑现——issue 正文无需任何编辑就能被接手者理解"的表述，正是整套方法论自洽性的证明。

八、在 Motion 仓库中实操：从 Recon 到计划的完整命令链

以下是在当前仓库直接复现整套审计工作流的实操路径：

Recon 阶段：读 AGENTS.md（monorepo 结构：framer-motion为 React 专属代码、motion为 re-export、motion-dom为原生 JS 动画库、motion-utils为纯函数与缓动；测试分 Jest 单元 / Cypress React E2E / Playwright 原生 JS E2E 三种）与 package.json（验证命令：yarn test、yarn test-e2e、yarn test-playwright、yarn lint、yarn build、yarn measure+node dev/inc/bundlesize.mjs测 bundle 大小）。

Audit 阶段：按本文第二部分九大类别逐项核查。以性能类别为例，可对照 PERFORMANCE_AUDIT.md 的方法自行验证：打开packages/motion-dom/src/animation/waapi/utils/accelerated-values.ts（x/scale/rotate简写未被加速）、packages/motion-dom/src/render/html/utils/build-styles.ts（每帧全量重建）与packages/motion-dom/src/effects/style/index.ts（仅变更键渲染），对比两条渲染路径的粒度差异。

Vet 阶段：每条发现亲自打开引用的源码复验——例如plans/README.md中"motion/mini扩展手势导出可行但低价值，与 mini bundle 体积优先目的矛盾"这类裁决，就是复验后按"类别目的"否决的典型。

Plan 阶段：按 plan-template.md 写计划，落到plans/目录并更新 plans/README.md 索引——当前仓库已有 38 个计划构成的可复用范式，新计划直接沿用其编号与状态管理约定。

结语

audit-playbook 之所以有效，是因为它把"代码审计"从玄学变成了一门有纪律的工程：证据是唯一通货（没有file:line的"可能有问题"不配称为发现）、格式是统一契约（六字段模板让不同子代理的产出可横向比较、可复验、可排序）、杠杆率是排序公理（impact ÷ effort，再按置信度与修复风险折现）、计划是产品（零上下文自包含 + 机器可检查的完成标准，让更弱的执行者模型也能落地）。Motion 仓库的plans/目录——从 38 个编号计划、每份计划盖着撰写时的提交 SHA，到"被否决发现永久归档防重复审计"的纪律——就是这个方法论在 500K 行动画 monorepo 上跑出真实成果的直接证据。无论你要审计的是动画库、CLI 还是后端服务，这套"证据驱动 + 杠杆优先 + 可执行交接"的框架都可以原样迁移。

• 前端
• UI组件