steering（项目代码分析引导）Skill 是什么？

项目代码分析引导Skill：把整个代码库变成所有 AI 代理都能读懂的"项目记忆"

它是什么：steering 是一个专做「代码库分析 + 项目内存（steering 上下文）生成与维护」的 AI 技能，技能 ID 为 13456。
核心产出：自动生成 structure.md（架构模式）、tech.md（技术栈）、product.md（业务上下文）、project.yml（机器可读配置），以及 memories/ 下的 5 类项目记忆文件。
最大差异点：它不是"读一次代码就忘"的分析工具，而是通过文档 + 内存 + 偏离检测，让项目知识在多次对话、多个代理之间持久复用。
交互方式：内置 Bootstrap（首次生成）、Sync（同步更新）、Review（审核）、Memory（内存管理）、Config（配置管理）、Auto-Sync（自动同步）六种模式，并强制"一次只问一个问题"的对话流。
一个必须提前知道的点：该技能有明确的文档语言政策，产出为英文版 .md + 日文版 .ja.md 成对交付，中文团队使用后通常需要自行补充或调整。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

基本信息

项目	内容
技能中文名	项目代码分析引导Skill
技能英文名	steering
技能 ID	13456
允许使用的工具	Read、Write、Bash、Glob、Grep
触发术语	steering、项目内存、代码库分析、自动更新上下文、生成 steering、架构模式、技术栈分析、项目结构、分析代码库、理解项目

它解决什么问题

无论是人还是 AI 代理，接手一个陌生仓库时都会遇到同一组痛点：架构靠猜、技术栈靠翻 package.json、业务背景靠读 README、上一次对话里搞明白的事情下一次又要重新搞一遍。steering 的思路很直接——把"理解项目"这件事本身做成可交付、可复用、可维护的资产：

分析目录结构，识别架构模式（Feature-first、Component-based、分层、DDD 等）；
从 package.json、requirements.txt、pom.xml 等文件提取技术栈；
从 README、ARCHITECTURE.md、代码注释中提炼业务上下文；
把结论固化成 steering 文档和 memories 内存，供所有代理参考；
后续代码变了，用 Sync / Auto-Sync 检测偏离并更新，避免文档腐烂。

一键安装的思路与步骤

该技能的安装方式与具体命令以官方说明为准，这里给出通用的落地步骤：

确认前提：准备好技能运行环境（支持技能/插件机制的 AI 编程助手或代理框架），并确保技能被允许调用 Read、Write、Bash、Glob、Grep 这五类工具——没有写权限就无法生成 steering 文件，没有 Glob/Grep 就无法做代码库分析。
安装技能：在技能市场或技能配置入口检索技能英文名 steering（技能 ID 13456）完成安装，具体入口与命令以官方说明为准。
确认工具授权：安装后在技能设置中核对允许工具清单，与上表一致即为正确。
验证是否生效：在会话中直接说出触发词（例如"分析代码库"或"生成 steering"）。如果技能已生效，代理会输出启动信息「🧭 Steering Agent 已启动」，并列出 structure.md、tech.md、product.md、project.yml、memories/ 五项管理对象，同时询问你要用哪种模式。看到这条消息即代表安装成功。
命令行能力（可选）：若需在会话外做内存与同步管理，可使用配套 CLI —— musubi-sync（steering 同步）与 musubi-remember（会话内存管理），其安装与运行依赖以官方说明为准。

一句话总结选它的理由：一次安装，长期受益——装完之后每次开新会话，代理都不再是"零基础新人"。

2. 该技能的主要功能和特点

架构模式检测：通过目录结构与命名规则推断代码组织方式，例如 src/features/ 对应 Feature-first、src/components/ 对应组件化、src/services/ 对应服务层、src/app/ 对应 App Router、src/domain/ 对应 DDD。
技术栈提取：识别语言、框架、库与工具链，前端、后端、ORM、构建工具分别从对应配置文件中取证，而不是靠"看代码猜"。
业务上下文理解：从 README、CONTRIBUTING.md、package.json 的 description 等位置提炼产品目的、目标用户与核心功能。
四类核心文档产出：structure.md（架构模式、目录结构、命名规则）、tech.md（技术栈、框架、工具、技术约束）、product.md（业务上下文、产品目的、目标用户）、project.yml（机器可读的项目配置，供代理自定义动作）。
五类项目内存：memories/architecture_decisions.md（ADR 风格决策记录）、development_workflow.md（构建/测试/部署流程）、domain_knowledge.md（业务逻辑与术语）、suggested_commands.md（常用 CLI 命令）、lessons_learned.md（经验教训与最佳实践）。
代理内存 CLI（v3.5.0 新增）：musubi-remember 提供 extract、export、import、condense、list、clear 六个动作，支持会话结束提炼学习、团队间共享知识、跨项目移植最佳实践、长会话中压缩内存。
偏离检测与改进建议：比对代码与 steering 文档，发现版本变更、新增目录、已删除路径、导入规范违例、废弃技术残留，并给出"委托给哪个角色去修"的推荐操作。
六种交互模式：Bootstrap、Sync、Review、Memory、Config、Auto-Sync，覆盖"建—更—查—记—配—自动"完整生命周期。
严格的"一问一答"纪律：每次只问一个问题并等待回答，禁止用列表一次性抛多个问题，避免用户被"问卷轰炸"，也让分析结果逐步确认、减少误判。
双语交付政策：所有文档先用英文创建，随后强制生成日文版（structure.md + structure.ja.md），引用时统一引用英文版 .md 路径，保证多代理协作时的引用一致性。
Auto-Sync 三种模式：交互式（默认，逐项确认）、--auto-approve（无确认，适合 CI/CD 定时任务）、--dry-run（只看变更不写文件，适合上线前预检）。

和普通工具比强在哪：普通代码分析工具输出的是"一次性报告"，普通对话式 AI 输出的是"一次性记忆"。steering 输出的是版本化的项目知识资产 + 更新机制 + 偏离告警，把"理解项目"从每次重来的消耗品变成了可沉淀的基础设施。

3. 如何使用该技能？

第 1 步：唤起技能

在对话中直接使用触发术语，例如：“用 steering 分析一下这个代码库”、“帮我生成项目内存”、“更新一下 steering 上下文”。技能启动后会出现模式选择菜单：

Bootstrap（首次生成）
Sync（更新/同步）
Review（审核）
Memory（内存管理）
Config（配置管理）

第 2 步：Bootstrap —— 首次生成（5 个问题，逐个问）

技能会依次只问一个问题，典型节奏如下：

项目的根目录是哪里？（示例：. 或 src/）
确认主要技术栈（已使用的）
确认项目目的 / 愿景（从 README 提取的内容）
确认目标用户 / 领域（从现有文档推测的内容）
是否还有额外重要信息

回答后，技能会先用 Glob/Read 分析仓库，并给出分析结果供你确认，例如：

📊 代码库分析结果架构模式：Feature-first organization（src/features/）、Component-based architecture、Service layer pattern 技术栈：React 18.2.0 + TypeScript、Next.js 14.0.0（App Router）、Prisma ORM + PostgreSQL、Tailwind CSS 业务上下文：SaaS 项目管理平台，目标用户为 10–50 人的远程优先初创公司这个分析结果正确吗？

你确认后，技能才落盘生成 structure.md / tech.md / product.md 及各自的 .ja.md 版本，并输出完成报告，提示"请检查这些文件，并根据需要手动调整"。

第 3 步：Sync —— 日常同步更新

询问"更新哪个文件"（全部自动检测 / 仅 structure.md / 仅 tech.md / 仅 product.md），然后重新分析代码库并输出偏离检测结果，例如：

🔍 偏离检测结果变更点：tech.md 中 React 18.2 → 18.3（从 package.json 检测）；structure.md 新增 API 路由模式（src/app/api/）代码漂移（警告）：src/components/ 下 10 个文件未遵循导入规范；旧 Redux 残留代码应处于迁移中反映这些变更吗？

确认后更新文档，并给出推荐操作（如"修复导入规范违例可委托给 Code Reviewer"）。

第 4 步：Memory —— 写入项目记忆

选择要写入的内存文件后，技能按 4 个问题逐步收集：条目文件名 → 条目标题 → 条目内容（建议包含 Context / Decision / Rationale / Impact 四段）→ 是否有额外信息。它明确要求"标注日期、提供背景、包含理由、记录影响"，并给出正例与反例，避免出现"Changed agents. Works now."这种无法复用的无效记录。

第 5 步：Auto-Sync —— 命令行自动同步

在终端执行 musubi-sync 走交互式确认；musubi-sync --dry-run 只展示变更；musubi-sync --auto-approve 直接应用，适合 CI/CD。内存管理则用 musubi-remember extract（提取学习）、musubi-remember export ./project-memory.json（导出）、musubi-remember import ./other-project-memory.json（导入他项目内存）、musubi-remember condense（压缩以适应上下文窗口）、musubi-remember list、musubi-remember clear。

第 6 步：检查产出

最终目录形如：steering/ 下含 structure.md、structure.ja.md、tech.md、tech.ja.md、product.md、product.ja.md、project.yml，以及 memories/（README、architecture_decisions、development_workflow、domain_knowledge、suggested_commands、lessons_learned）。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
steering（项目代码分析引导Skill）	项目级"记忆中枢"，把代码库理解沉淀为可维护文档与内存	架构/技术栈/业务三路分析、四类文档 + 五类内存、偏离检测、Auto-Sync、内存 CLI	需安装技能并授予 Read/Write/Bash/Glob/Grep；CLI 依赖以官方说明为准	多代理协作、长期维护的中大型仓库、需要跨会话保持一致理解的团队	优势：有更新机制与漂移告警，知识可复用可移植；不足：产出为英文 + 日文双语，中文团队需额外适配，且首次 Bootstrap 需逐项确认，略花时间
手工维护 README / ARCHITECTURE.md	传统文档方案	由人撰写架构说明与开发指南	零门槛，但完全依赖人的自觉	小团队、早期项目	优势：灵活、无额外依赖；不足：极易过期，没人写就没人看，无法被代理结构化消费
通用 AI 编程助手的会话内记忆	对话级上下文记忆	记住本次或近期对话中的约定	零配置	短周期、单人任务	优势：即开即用；不足：会话结束即失效，跨会话、跨代理无法继承，也无法检测文档与代码的偏离
传统静态代码分析与依赖扫描工具	代码质量 / 依赖治理	语法规则检查、依赖漏洞扫描、圈复杂度统计	需配置规则集	质量门禁、CI 流水线	优势：规则精确、可自动化；不足：只回答"代码是否合规"，不回答"项目为什么这样设计"，缺少业务上下文与决策记录

选择建议：如果只是想让 AI 帮你看一眼仓库，用通用助手对话即可；如果你希望团队里所有人、所有代理对项目的理解长期保持一致，steering 这类"文档 + 内存 + 同步机制"的方案才真正解决问题。

5. 该技能的典型应用场景与实际体验情况

场景一：新成员（含 AI 代理）入职式接手老仓库

角色与痛点：刚加入的开发者或新接入的代理面对几十万行代码，只能靠翻目录和问人；问十个人得到十种架构描述。
使用方式：跑一次 Bootstrap，先确认根目录与技术栈，再让技能输出分析结果供人工校正，最后生成 structure.md / tech.md / product.md。
实际体验：分析结果以"待确认"形式给出，而不是直接落盘，这一点很关键——避免了"AI 猜错架构然后全组照着错的文档干活"。上手难度低，主要成本在于逐项确认的几分钟。

场景二：技术栈升级后的文档腐烂治理

角色与痛点：框架从 React 18.2 升到 18.3、新增 src/app/api/ 路由，文档还停留在半年前，新人照着旧文档写代码。
使用方式：musubi-sync --dry-run 先看变更清单，确认无误后交互式应用，或放进 CI 用 --auto-approve 定期同步。
实际体验：偏离检测不仅报"版本变了"，还会报"代码漂移"——比如 10 个文件未遵循导入规范、Redux 残留代码未清理，并附上"该委托给谁修"的推荐。这是它比单纯文档工具更有价值的地方：把文档同步变成了代码治理的入口。

场景三：跨会话、跨成员的经验沉淀

角色与痛点：一次长会话里踩过的坑（比如上下文溢出、某次架构取舍的原因），下一次没人记得。
使用方式：在 Memory 模式下按 Context / Decision / Rationale / Impact 四段式写入 memories/architecture_decisions.md 或 lessons_learned.md；会话结束时用 musubi-remember extract 提炼，export 成 JSON 分享给同事，import 到新项目复用。
实际体验：条目要求"带日期、带背景、带理由、带影响"，一开始会觉得啰嗦，但写几条后会发现——半年后还能看懂当初为什么这么选。注意要克制，把"什么该记"筛选清楚，否则 memories 会膨胀。

场景四：多代理协作的统一上下文供给

角色与痛点：不同职责的代理各自理解项目，产出互相打架。
使用方式：由 steering 统一产出并维护上下文，其他代理统一引用英文版 steering/structure.md、steering/tech.md 等路径。
实际体验：引用规范统一后，协作摩擦明显下降。注意事项：该技能的双语政策是"英文必建、日文必建"，且明确禁止"只建英文跳过日文"或"先建完所有英文再统一补日文"。中文团队接入时需要提前规划——是接受这套双语规范，还是在遵循其"引用英文主文档"原则的前提下自行扩展中文版，建议在团队内先对齐再做批量生成。

6. 该技能能为用户带来的价值

把"理解项目"的成本从重复支出变成一次性投入：过去每开一个新会话、每来一个新成员，理解成本都要重付一遍；现在由 steering 文档 + memories 统一供给，边际成本趋近于零。
显著降低 AI 协作的"失忆率"：跨会话持久知识、持续学习、代理协作是该技能的设计目的，配合 musubi-remember condense 压缩上下文，可缓解长会话中的上下文窗口压力。
让文档不再腐烂：Sync / Auto-Sync 的偏离检测把"文档过期"从不可见问题变成可告警、可修复的任务，并直接给出修复责任建议。
降低新人上手门槛：一份结构化的 structure.md + tech.md + product.md，等于给每个新人和每个代理发了一本随项目更新的"项目说明书"。
知识可移植、可共享：内存支持 export / import，团队间的知识共享、项目间的最佳实践移植都变成一条命令的事。
长期价值：architectural decisions 与 lessons learned 会随时间积累成组织的技术资产——它记录的不只是"代码长什么样"，更是"为什么长成这样"。

7. 常见问题 FAQ

Q1：怎么安装这个技能？装完怎么确认生效？ A：在技能市场或技能配置入口检索英文名 steering（技能 ID 13456）完成安装，具体安装命令与入口以官方说明为准。装完后确认技能已获得 Read、Write、Bash、Glob、Grep 五项工具权限，然后在对话里说一句"分析代码库"或"生成 steering"——若出现「🧭 Steering Agent 已启动」的模式选择菜单，说明已生效。

Q2：这个技能收费吗？ A：技能本身的使用成本取决于你所使用的 AI 平台/代理框架的计费方式，本技能详情中未包含定价信息，请以官方说明为准。需要注意的是它会读取并写入项目文件，调用频率较高时可能消耗更多模型额度。

Q3：它适合谁用？小项目有必要吗？ A：最适合三类用户：长期维护的中大型仓库、多人 + 多代理协作的团队、以及需要频繁让 AI 接手陌生代码库的开发者。小项目或一次性脚本用它略重；但如果项目会持续演进、且你经常抱怨"AI 每次都要重新解释一遍项目"，那它就值得一试。

Q4：我不懂英文和日文，产出是英文 + 日文怎么办？ A：这是该技能明确的文档语言政策：先建英文版 .md，再强制生成日文版 .ja.md，且引用其他代理成果时必须引用英文版路径。中文团队可以在遵循"英文为主文档、引用统一用 .md"这一原则的前提下，自行增补中文版；建议先在团队内统一规范，避免引用混乱。

Q5：它和直接用 AI 读代码、或者自己写架构文档，怎么选？ A：只是想快速了解仓库结构，直接让 AI 读代码最快；想沉淀成规范文档但能接受人工维护，手写 README 也可以。如果你要的是"能自动检测偏离、能跨会话记忆、能被多个代理共同引用"的长期方案，选 steering 更合适——它的差异点不在"分析得有多深"，而在"分析结果能不能持续保鲜"。