团队里经常会出现这种情况。
有个人把AI用得很顺，写需求、查代码、整理客户记录都很快。大家问他怎么做，他发来一段很长的提示词。
其他人复制过去，效果却不一样。
不是模型突然变笨了，而是那段提示词背后还藏着很多东西：他知道去哪找资料，知道什么结果不可信，知道哪些字段必须检查，也知道出错以后怎么补。
这些没有写出来的判断，才是真正的能力。
提示词只是任务入口
一条提示词通常只能说明“这次想让AI做什么”。
一个能被团队复用的Skill，还应该包含：
适用场景
+ 输入资料
+ 执行步骤
+ 工具权限
+ 输出格式
+ 检查规则
+ 失败处理
+ 维护负责人这里的Skill不一定非要是某个平台的专用文件。
它可以是Claude Code使用的项目指令、Codex读取的AGENTS.md、Dify里的工作流、FastGPT里的应用流程，也可以先是一份普通Markdown操作说明。
关键不在名字，而在下一位同事能不能按照它完成同一项工作。
先挑一条已经重复成功的做法
不要把第一次成功的聊天记录马上包装成团队标准。
至少重复使用三到五次，确认：
- 输入资料大致稳定；
- 输出确实能节省工作；
- 常见错误已经出现过；
- 人工知道检查什么；
- 换一个人还能理解；
- 这项工作值得持续维护。
如果每次任务差异都很大，或者结果完全依赖某位专家临场判断，更适合保留为个人辅助方法，不必急着做成自动流程。
用“任务说明卡”替代神奇提示词
可以先把个人做法整理成这张卡：
名称：接口代码审查
适用范围：ASP.NET Core服务的Pull Request初审
输入：PR diff、相关Issue、项目AGENTS.md、测试结果
任务：检查业务遗漏、异常处理、并发、日志、权限和测试
不能做：不直接合并，不修改生产配置，不猜测缺失需求
输出：问题位置、影响、建议、证据；按高/中/低风险排序
人工确认：模块负责人判断是否阻止合并
失败处理：上下文不足时列出缺少资料，不给确定结论这比“你是一名资深架构师，请全面审查代码”有用得多。
它把适用范围、输入和责任说清楚了。
一个需求评审Skill怎么形成
假设产品经理经常把会议记录整理成需求。
第一版可能只是一句话：“请把会议内容整理成PRD。”
用几次以后，会发现AI经常把客户的试探性表达写成确定需求，也会漏掉尚未确认的接口和数据范围。
这时可以把流程拆开：
会议记录
→ 区分客户原话、产品判断和待确认问题
→ 提取用户、场景、触发条件和预期结果
→ 生成验收条件草稿
→ 标记缺少的数据、权限和异常场景
→ 产品经理确认
→ 写入需求系统再准备一组检查问题：
- 有没有把“可能”写成“必须”；
- 是否说明不做什么；
- 是否有异常和权限场景；
- 验收条件能不能被测试；
- 哪个结论找不到原始依据。
当这些规则稳定下来，它才开始像一个团队Skill。
AI Coding里的Skill更容易被看见
使用Claude Code或Codex时，团队可以把项目规则直接放进仓库。
Codex使用AGENTS.md，Claude Code可以使用CLAUDE.md。国内团队也可以用同一思路测试通义灵码等编码工具。
文件里不需要堆满编码规范，先写最容易出事故的内容：
- 构建和测试命令；
- 项目分层和现有封装；
- 不能修改的生成目录；
- 数据库迁移方式；
- 日志、异常和配置要求；
- 完成任务后的验证清单；
- 禁止直接执行的生产操作。
规则应该跟代码一起Review。
项目结构变化了，Skill也要改。否则AI会非常认真地遵守一套已经过期的做法。
业务流程可以放到Dify或FastGPT
对于客户问答、资料整理、销售跟进这类工作，可以把稳定步骤做成Dify或FastGPT流程。
例如销售会议跟进：
输入会议记录
→ 提取客户、需求、异议、承诺和下一步
→ 检查是否缺少时间与负责人
→ 生成CRM草稿
→ 销售确认
→ 才允许写回CRM流程里要保留原始记录链接。AI生成的客户需求不能替代客户原话，报价、交期和合同条件不能自动承诺。
第一阶段甚至不用接CRM。
先让员工复制一段脱敏会议记录，确认输出模板稳定，再考虑API和自动写回。
Skill需要版本，不是写完就结束
建议每个Skill至少记录：
名称：
版本：
负责人：
适用工具：
适用任务：
最后更新：
输入要求：
输出要求：
人工确认：
已知问题：
变更记录：修改时保留一个小测试集。
需求评审可以保存五段脱敏会议记录，代码审查可以保存三个历史PR，客服可以保存二十个常见问题。每次改Skill以后重新跑一遍，确认旧能力没有被新规则破坏。
三种最常见的失败
第一种，Skill写得太通用。
“分析问题、给出专业建议”适用于任何工作，也指导不了具体工作。
第二种，规则太多。
把几十页制度全部塞进指令，模型抓不到重点，维护的人也不敢改。规则应该围绕当前任务，背景知识放进可引用的知识库。
第三种，没有负责人。
提示词保存在群文件里，流程出错时没人知道该找谁。时间一长，大家各自复制一份继续修改，又回到个人方法。
怎么判断Skill真的属于团队
可以做一个很简单的交接测试。
找一位没有参与编写的同岗位员工，只给他Skill、样例输入和工具账号。观察他能不能完成任务，哪里需要额外口头解释。
重点看：
- 第一次完成需要多久；
- 输出有多少可以采用；
- 是否知道什么时候应该停止并找人；
- 两个人的结果差异有多大；
- 错误能不能追到具体规则；
- 负责人能不能独立更新。
真正的团队能力，不是“幸好某个人有一条好提示词”。
而是这个人不在场，团队仍然知道资料在哪里、步骤怎么走、结果怎么查、最后由谁负责。
暂无评论