技术路线图 Skill 适合把架构改造、技术债和平台能力建设整理成有先后关系的计划。可以从 RefoundAI/Lenny 的 technical-roadmaps 入手：先说明当前系统的问题与限制，再形成技术原则和行动。它能帮助你把思路写清楚；具体依赖、迁移顺序和完成条件，需要结合本地项目资料补上，不能只让 AI 生成一张季度排期表。
想从现有项目开始，可以在墨刀 AI 客户端中整理架构说明、接口清单和问题记录，围绕同一批文件持续修改路线图；已有 Codex 工作流的团队，也可以先加载现成 Skill 读项目，再把需要讨论的页面和流程交给墨刀。先解决“为什么改、先改什么”，再决定图怎样画。
技术路线图、产品路线图和科研技术路线图有什么区别
搜索“技术路线图 Skill”时，容易把三类不同任务混在一起。工程团队的技术路线图要回答系统怎样演进；产品路线图回答为哪些用户解决什么问题；科研路线图则组织研究问题、方法和验证过程。它们都可能有箭头和阶段，但输入材料与判断标准不同。
| 类型 | 主要问题 | 典型内容 |
|---|---|---|
| 技术路线图 | 为了支持业务，系统能力怎样演进？ | 架构、接口、数据、技术债、迁移依赖、退出旧方案的条件 |
| 产品路线图 | 先为哪类用户交付哪些价值？ | 目标、机会、主题、功能范围、版本顺序 |
| 科研技术路线图 | 用什么研究方法检验问题？ | 对象、实验、数据、方法、证据和研究结论 |
例如“下季度支持集团多组织采购”是产品方向；“建立组织身份、统一权限检查、迁移历史数据、支持审计”才是实现这个方向的技术路线。产品优先级还没确定时，可先看AI 生成产品路线图的方法；已经确定方向但技术改造排不清时，继续做技术路线。
选用现成 Skill：Technical Roadmaps 能帮到哪里
RefoundAI 的 Technical Roadmaps来自其 Lenny Skills 项目，围绕技术策略的书面表达，使用“诊断—指导原则—行动”的结构，并提醒团队优先用已有技术解决业务问题。它适合开始讨论技术方向，不是自动读取所有依赖并给出准确工期的项目管理系统。
这份 Skill 的价值，是让提问更聚焦。例如，先问“目前的技术限制具体影响什么任务”，再问“哪些原则约束后续选择”。如果问题只是采购单查询跨组织混乱，就不该在没有依据时把路线图扩大成微服务、数据库和前端框架同时重写。
需要注意版本：原作者仓库已重组为 2.0，旧版的 technical-roadmaps 不在当前主分支同名目录中。原作者介绍页仍能查到方法，但旧页面上的同名安装命令和 ZIP 入口不能直接当成当前可用路径。下面固定使用官方仓库中仍可读取的历史版本，方便复现；它不是“最新版”。
| 入口 | 适合的任务 | 如何使用 |
|---|---|---|
历史版 technical-roadmaps | 围绕当前挑战、技术原则和行动写路线图 | 使用下方固定版本，保留完整文件夹和引用资料 |
| 当前版 engineering-health | 工程健康、技术债、交付流程与开发者体验 | 问题属于工程效率和技术投入时选用；它不是旧 Skill 的同名替换 |
| 只需要排产品功能优先级 | 业务目标、机会取舍与版本范围 | 使用产品路线图方法，不把技术 Skill 当作所有规划任务的通用答案 |
从官方固定版本取得 Skill，再检查是否加载
打开官方历史版本的 technical-roadmaps 目录。该版本对应提交 280a57aa；可从官方仓库下载这一版本 ZIP，解压后找到 skills/technical-roadmaps。保留原项目的 MIT 许可与来源信息，不把下载来的技能改名成自己的原创产品。
- 检查文件夹内有
SKILL.md，以及它引用的references/guest-insights.md。 - 在计划使用的项目目录中建立
.agents/skills，把整个technical-roadmaps文件夹放进去。 - 在 Codex 中打开这个项目。CLI 或 IDE 扩展可通过
/skills查看，并用$technical-roadmaps指定技能；未出现时检查目录层级后重新加载。 - 先让 AI 说明这份技能处理什么任务、准备读取哪些材料，再提交技术规划需求。
project/
.agents/
skills/
technical-roadmaps/
SKILL.md
references/
guest-insights.md
architecture.md
constraints.md
issues.md放置完成后，打开 SKILL.md 确认 name 为 technical-roadmaps，并检查它引用的文件没有缺失。加载方式按Codex 官方 Skills 文档操作；不同客户端的技能目录不要混用。完整的加载与调用排查可参考Skills 安装与首次调用教程。
在墨刀 AI 客户端使用第三方技能时，先检查当前版本的添加技能入口接受的文件形式；添加后确认技能名称及说明。如果只是把资料交给 AI 阅读，则说明“按这份方法分析文件”，不要把“读过一个文件”当作客户端已安装并启用了该 Skill。
先准备四类材料，避免 AI 凭空安排技术投资
以一个采购审批系统为例：现有系统服务单一组织，接下来要支持集团下的多个组织。采购员只能处理本组织单据，集团审计员需要跨组织查看授权范围内的记录，管理员需要配置权限。技术路线必须同时回应页面操作、权限规则和数据迁移。
| 文件 | 写什么 | 容易遗漏的内容 |
|---|---|---|
architecture.md | 登录、用户、组织、采购单、审批与审计之间怎样连接 | 同一权限规则是否在多个服务里各写一份 |
constraints.md | 沿用现有数据库和身份系统；迁移时不能中断日常审批 | 外部身份系统能否及时提供组织信息，谁负责配合 |
issues.md | 已发现的问题、复现步骤、相关接口或页面 | 把“权限很乱”具体到哪个角色看到了哪个对象 |
decisions.md | 已确定、待讨论、不做的事项和理由 | 新加技术是必需能力，还是团队偏好 |
文件可以很短，但要把事实与假设分开。例如：“历史采购单没有组织字段”属于可查证结构；“加一个组织字段就够了”属于待验证方案。将两者混写，模型很容易直接排出迁移计划，遗漏旧账号归属与跨组织审批的规则。
第一次调用：先得到技术诊断，不急着填日期
让 Skill 从材料提取问题与原则，再形成少量有因果关系的行动。第一次就要求“给我完整季度路线图”，模型往往会把不确定的事情写成确定承诺。
请使用 $technical-roadmaps，读取 architecture.md、constraints.md、
issues.md、decisions.md，为采购审批系统规划多组织能力。
先输出：
1. 当前最影响目标的技术问题；每项引用对应文件或位置。
2. 需要遵守的技术原则及原因。
3. 实现目标需要的行动，以及每项依赖什么前置结果。
4. 暂不做的事项和待确认信息。
保留现有技术栈；资料没有的数据、人员容量、工期不能自行补齐。
这一轮只整理方案，不修改源码，不执行迁移。合理的诊断应落到具体阻碍：“历史单据无法确定组织归属，直接按新权限过滤可能导致正常单据消失”。对应的技术原则可以是：“新规则只对已确认组织归属的数据生效；无法确认的数据进入人工处理清单”。行动则包括补充组织映射、核对权限策略，以及验证旧单据访问。
相反，“升级技术架构，增强系统安全性”没有告诉团队先改哪一处，也不能指导原型中的角色切换和空结果提示。遇到这种输出，追问具体页面、接口、字段和失败情况，不要只要求写得更详细。
第二次调用：把依赖、里程碑和退出条件连起来
当诊断和原则清楚后，再组织阶段。技术路线中的里程碑应描述“具备什么能力”，而不是“完成了一次评审”或“写完某份文档”。下面是采购审批任务的一种讨论结构，实际顺序要结合项目材料调整。
| 阶段 | 要得到的能力 | 依赖与完成条件 |
|---|---|---|
| 组织与角色定义 | 每个试点账号的组织、角色与可见范围可解释 | 业务确认角色矩阵；旧账号归属不明项有处理人 |
| 统一权限检查 | 列表、详情和审批操作遵守同一套规则 | 依赖角色矩阵；包含越权访问、跨组织审批和拒绝反馈的验证记录 |
| 数据映射与迁移演练 | 试点采购单可以按组织正确查询 | 依赖组织标识；异常单据可定位，迁移失败有恢复办法 |
| 试点切换 | 一个试点组织完成日常采购审批 | 权限与数据条件同时满足；可停止扩大范围并恢复既定路径 |
| 扩大范围与退出旧规则 | 其他组织逐步接入，旧规则有明确退出计划 | 依赖试点结果、支持能力与遗留数据处理，不只看新功能已上线 |
有些行动可以并行：角色原型评审与历史数据盘点可以一起开始。但“确定角色规则”没结束前，就把所有接口校验写死，可能让后续修改波及多个系统。画依赖箭头时应标明原因，例如“依赖组织标识”，而不只是按视觉顺序连接卡片。
基于已确认的诊断与原则，把行动整理为技术路线图表。
每项包含：目标能力、前置依赖、负责人待确认项、完成条件、
失败时的恢复路径，以及能否与其他事项并行。
日期先留空；使用“当前、下一阶段、后续”表达确定性。
单独列出会改变用户界面的事项，供产品和设计同步原型。
检查有没有把“评审结束”误当成“能力已经可用”。
把技术路线接到墨刀原型，避免只有研发看得懂
技术工作影响用户时，原型可以让依赖更容易讨论。在采购系统中，为采购员、组织管理员、集团审计员准备相应页面状态：当前组织怎样显示、切换组织后列表是否重置、无权查看单据时怎么提示、审批操作被拒绝后怎样继续。
不要把全部数据库与服务依赖塞进一张用户界面。路线图保留系统关系，原型展示用户会遇到的结果；用同一个事项名称连接两边。例如“统一权限检查”对应“无权限单据提示”和“跨组织审批确认”，评审时才能知道改一个权限规则会影响哪些页面。
在墨刀 AI 客户端中，可以把路线图、角色矩阵和原型需求放在同一项目材料里，要求每次修改保留既定角色与依赖。使用 Codex 的团队可通过墨刀 AI MCP生成原型，或读取已有原型核对页面状态；连接工具与加载规划 Skill 分别负责执行能力和思考步骤，不要把两者混为一件事。
团队讨论时优先确认两类问题：技术改造是否真的支持了目标任务，以及用户需要付出多少迁移成本。比如管理员能否看懂旧数据待处理清单，比在路线图上增加一个“智能化升级”阶段更能说明当前方案是否可用。
路线图不可靠，通常能从这些结果看出来
- 只有技术名词，没有对应问题：要求每个新增组件说明它解决哪个已观察到的限制；说不清就先放回候选。
- 日期很整齐，依赖不清楚：先补外部系统、数据与权限前置，再由负责人评估容量，不能用自动排期代替估算。
- 只有新方案，没有旧方案退出：补迁移、兼容、停止扩大范围和恢复条件，否则上线后可能长期维护两套逻辑。
- 每项都标成最高优先级：先区分目标必需、前置验证、可延后和暂不做，再讨论投入。
- Skill 读到了方法，没读到项目：要求列出实际引用的文件和未获取的信息；缺少材料的部分保留待确认。
先挑一个已经影响业务的技术问题，把现有文件交给 Skill 得到诊断、原则和依赖表，再用原型把用户侧变化讲清楚。这样路线图的每一步都能解释为什么需要、依赖什么，以及完成后用户会得到什么。
