从提示词到Skill，把一次成功变成团队能力
团队里经常会出现这种情况。有个人把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、样例输入和工具账号。观察他能不能完成任务，哪里需要额外口头解释。重点看：第一次完成需要多久；输出有多少可以采用；是否知道什么时候应该停止并找人；两个人的结果差异有多大；错误能不能追到具体规则；负责人能不能独立更新。真正的团队能力，不是“幸好某个人有一条好提示词”。而是这个人不在场，团队仍然知道资料在哪里、步骤怎么走、结果怎么查、最后由谁负责。
带团队最怕的不是慢，是问题没人说
带团队以后，我越来越怕一种安静。不是大家不说话的安静。而是每个人都说“还行”“差不多”“在处理”，但到了联调或者上线前，问题突然冒出来。接口没对上。数据口径不一致。设备现场情况跟最初理解不一样。某个功能其实卡了三天，只是没人说。这时候再补，成本就很高了。我以前最容易被“差不多”骗到。周三问进度，说差不多。周四问联调，说还行。周五下午准备合并，才发现核心流程还没完整跑通过。那种时候你再想拆风险、调资源、改方案，选择已经很少了。一、慢一点不可怕，假装顺利才可怕项目慢一点，有时候是正常的。需求复杂，系统历史包袱重，新人需要时间，外部依赖没到位，这些都会让项目变慢。慢本身不是最大问题。最大问题是慢了没人说。因为没人说，负责人以为进度正常。测试以为开发能按时提测。业务以为上线时间没变。等到问题暴露时，所有人的预期都已经被打乱。这时候团队就容易进入一种很糟的状态：白天解释，晚上补锅，第二天继续说“快好了”。而且这种状态会传染。一个人不说问题，另一个人也不好意思说。大家都在撑，最后撑到谁都撑不住。二、为什么大家不愿意说卡住了很多时候，不是大家故意隐瞒。有的人觉得自己再试试就能解决，不想显得能力不行。有的人怕一说卡住，就被追问为什么没早点处理。有的人不知道这个问题会影响别人，以为只是自己这块慢一点。还有的人之前说过问题，但得到的反馈是“你先想办法”，后来就不太愿意说了。所以风险不暴露，往往不是一个人的问题。它跟团队氛围、反馈方式、任务拆分和负责人处理问题的方式都有关系。如果每次有人暴露问题，迎来的都是责备，那下次大家就会更晚说。三、技术负责人要让“说问题”变得正常我现在更愿意在项目开始时就讲清楚：问题早点说，不代表你不行。真正麻烦的是你已经卡住，却让别人以为你没卡住。这个口头说一次没用。要在日常里形成习惯。比如任务同步时，不只问“做完了吗”，还要问“有什么卡点”。比如有人提早暴露风险，不要第一句话就问“为什么现在才说”，而是先处理影响。比如一个问题连续卡两天，就要主动拉人一起看，而不是让负责人靠感觉猜。风险暴露得越早，处理方式越多。暴露得越晚，就只能靠加班和妥协。四、卡住不是失败，没反馈才是失败有些复杂问题，本来就会卡。比如旧系统迁移。比如设备协议兼容。比如性能瓶颈。比如跨部门接口联调。这些事情不可能一路顺。所以团队不能把“卡住”当成丢脸。真正要建立的是一种反馈机制：我现在在哪里，遇到了什么问题，预计影响什么，需要谁帮忙，下一步怎么处理。这几句话说清楚，团队就还有机会调整。后来我会让大家用很普通的话说卡点，不需要包装：我这里卡在设备回包不稳定；我这里缺一个确认口径；我这里需要后端帮我看一下日志；我这里如果今天过不去，会影响明天提测。说清楚这些，比一句“还在处理中”有用得多。五、小结带团队最怕的不是慢。慢可以调整计划，可以拆范围，可以加资源，可以换方案。最怕的是问题没人说。没人说，所有判断都是假的。技术负责人要做的，不是逼大家每天报喜，而是让团队敢于报忧，并且知道报忧以后事情会被处理，而不是人先被处理。本系列：上一篇：技术负责人离代码多远比较合适下一篇：有时候你以为是在帮忙，其实是在替团队做决定系列目录：带团队以后，我才明白的事
小团队一聊流程，气氛经常有点微妙。有人觉得流程是大公司那一套，麻烦、慢、形式主义。也有人觉得没有流程不行，需求乱、上线乱、问题也乱。这两种感觉都对一部分。小团队确实怕流程太重。人本来就少，再天天填表、开会、走审批，很容易把行动力磨掉。但完全没有流程也不现实。只靠口头同步和个人自觉，团队稍微忙一点就会丢东西。小团队最容易在流程上走两个极端。一种是完全不想要流程，觉得流程会拖慢速度。另一种是一出问题就加流程，加表单、加审批、加日报，最后每个人都在填东西。我现在更愿意问：这个流程到底是在解决哪个反复出现的问题？如果回答不上来，它很可能只是焦虑的外壳。一、流程不是为了显得正规流程最容易走偏的地方，是为了看起来正规。需求要有模板，会议要有纪要，代码要有审批，上线要有清单。每一项单独看都没错，但如果只是照搬，团队会很快疲惫。流程应该先回答一个问题：它解决了什么反复发生的麻烦？如果没有解决真实问题，只是多了一道动作，那它就是负担。比如一个三个人的小团队，每天坐在一起开发，非要写复杂日报，可能意义不大。但如果这个团队经常上线漏配置，那一张上线检查清单就很值。二、重复出错的地方需要流程小团队最应该加流程的地方，是重复出错的地方。比如：需求经常说不清，就加轻量需求确认。上线经常漏步骤，就加发布清单。接口经常对不上，就加接口契约。线上问题没人跟，就加故障记录。新人总是问同样问题，就加上手文档。流程不是为了限制人，而是为了少踩同一个坑。如果一个问题只发生一次，可能不需要流程。重复发生，就说明不能只靠提醒。三、流程要足够轻小团队的流程一定要轻。轻不是随便，而是刚好够用。比如需求确认不一定要写十页文档，可以只写：目标是什么？ 本期做什么？ 本期不做什么？ 验收标准是什么？ 风险和依赖是什么？上线清单也不一定复杂，可以只列：数据库脚本是否执行？ 配置是否更新？ 回滚方式是否确认？ 通知谁验收？ 监控看哪里？能用一页说清，就不要搞成一个系统。四、流程要服务协作，不要替代思考流程还有一个风险：大家开始依赖流程，而不是思考。表填了，就觉得需求清楚了。评审开了，就觉得风险处理了。Review 点了通过，就觉得质量没问题。但流程只是提醒你该看什么，不会替你判断。技术负责人要经常看流程有没有变成形式。如果会议纪要没人看，需求模板没人认真填，Review 只剩点按钮，那就要停下来调整。流程不是越多越成熟，能让问题更早被看见才有价值。五、团队长大一点，流程也要跟着变三个人、十个人、三十个人，需要的流程不一样。三个人可以靠随时沟通，十个人开始需要任务边界和文档，三十个人就需要更明确的发布、权限、质量和协作机制。流程不是一次设计好就不变。小团队早期可以先保留几个关键动作：需求确认。任务拆分。Code Review。提测验收。上线检查。问题复盘。其他的，等问题真实出现再加。六、小结小团队不是不要流程，而是不要为了流程而流程。真正有用的流程，应该解决重复出错、信息丢失、责任不清和风险不可见的问题。如果一个流程让团队更清楚、更稳定、更少返工，它就值得保留。如果一个流程只是让大家多填东西、多开会、多等人，那就应该减掉。技术负责人要做的不是把团队变成大公司，而是在团队刚好需要的时候，给它加上刚好够用的骨架。本系列：上一篇：绩效、激励和团队安全感下一篇：无系列目录：一个技术负责人眼里的软件团队
很多新人进团队，第一句话就是：“你先熟悉一下代码。”这句话太常见了。说的人通常也没恶意。团队忙，项目赶，老同事手里都有活，先让新人自己看看，似乎是最自然的安排。但问题是，一个陌生系统的代码，对新人来说就像一座没地图的城市。他能看到街道，但不知道哪里是主路，哪里是小巷，哪里以前出过事故，哪里看起来破但不能随便拆。新人刚进团队时，最怕听到一句话：“你先看代码。”这句话听起来很正常，但很多系统不是靠看代码就能看懂的。代码里有历史妥协，有业务黑话，有现场特殊规则，还有很多当年没人写下来的判断。新人看两周代码还不敢动，不一定是他能力差。可能是团队没有给他一条能走进去的路。一、看代码不是上手路径代码当然要看。但只看代码，很难建立完整理解。新人需要知道的不只是“这个类做什么”，还包括：这个系统服务什么业务。哪些模块是核心链路。哪些地方历史包袱比较重。本地环境怎么跑。提测和上线流程是什么。出问题时看哪些日志。团队默认的代码风格和质量标准是什么。这些东西如果没人讲，新人只能靠猜。猜得慢，就显得不主动。猜错了，就容易踩坑。二、第一周最好给一张地图新人刚来时，我觉得最重要的不是马上产出，而是给他一张地图。这张地图不一定很正式，但要能帮助他建立方向感。比如：第一天：跑通本地环境，了解业务主流程。 第二天：看订单、客户、权限三个核心模块。 第三天：跟一次需求评审和一次代码 Review。 第四天：修一个低风险 bug。 第五天：和负责人过一遍系统问题和疑问。这种安排比“你先看看”有效很多。新人知道自己每天要完成什么，也知道遇到问题该问谁。三、任务要小，但不能假新人上手任务最好小一点。但小不代表随便找一个无关紧要的边角任务。太假的任务没有上下文，新人做完也不理解系统。我更喜欢给新人安排“低风险、真链路”的任务。比如一个真实 bug，一个小字段调整，一个后台列表优化，一个接口返回补充。任务不大，但能让他走完整个流程：理解需求、改代码、跑测试、提交 Review、提测、上线。走完一次闭环，比看一周代码更有用。四、反馈要及时，不要等试用期结束新人最怕的是不知道自己做得怎么样。代码交了没人看，问题问了没人回，任务做完也没人说哪里好哪里不好。时间久了，人会越来越没底。技术负责人或者带教人要给及时反馈。反馈不用很重，可以很简单：这个地方处理得不错。这里缺少异常判断。这个命名不太符合团队习惯。下次提测前先自己跑一下这几个用例。及时反馈能帮新人调整方向。等到一个月以后再集中说问题，很多习惯已经形成了。五、培养新人其实是在整理团队知识新人问的问题，有时会暴露团队自己的问题。为什么本地环境这么难跑？为什么接口文档找不到？为什么这个字段没人敢改？为什么上线流程只有某个人知道？这些不是新人不懂，而是团队知识没有沉淀。所以培养新人不是单向付出。它会逼团队把很多“老员工脑子里的东西”写下来、讲清楚、流程化。从这个角度看，新人上手慢，有时不是新人慢，是团队的知识太散。六、小结新人培养不能只靠“你先看代码”。代码只是系统的一部分。业务背景、模块边界、开发流程、质量标准、反馈机制，这些都要有人带着走一遍。一个新人能不能尽快进入状态，不只看他个人能力，也看团队有没有给他一条能走的路。把新人带好，其实也是把团队自己整理清楚。本系列：上一篇：怎么开一个不浪费人的技术会议下一篇：绩效、激励和团队安全感系列目录：一个技术负责人眼里的软件团队
软件团队里，会议很容易越开越多。需求评审、技术评审、站会、周会、复盘会、临时对齐会。日历看起来很充实，群里也一直有人说“拉个会聊一下”。但很多人心里其实清楚：有些会开完以后，问题并没有变清楚，只是大家一起把时间花掉了。技术会议尤其如此。我现在判断一个技术会议有没有价值，不太看它开了多久，也不看参加的人多不多。我会看会议结束以后，有没有少掉一个不确定性。如果开完会，大家只是把各自的立场又讲了一遍，纪要里写着“后续继续跟进”，那这个会大概率没有解决问题。真正有用的会，哪怕只有二十分钟，也应该让团队知道下一步谁做什么、风险在哪里、什么时候再看结果。一、不是所有问题都需要开会有些问题适合开会。比如方案有明显分歧，涉及多个模块，风险需要一起判断，或者需要当场做决策。但有些问题不适合。比如只是同步一个接口字段，说明一个简单规则，确认一个时间点。这些用文档、评论、群消息可能更快。我见过一些会，五六个人坐在一起，讨论的其实是一个字段叫什么。最后半小时过去了，大家都累。开会之前可以先问一句：这件事需要大家同时在线讨论吗？如果不需要，就不要开。二、会议要从问题开始，不要从流程开始很多会议一开始就进入流程。“我们今天评审一下方案。”然后从第一页 PPT 开始讲，讲背景、讲架构、讲模块、讲数据流。讲完以后，大家有点困，也不知道该反馈什么。我更喜欢会议一开始先把问题说出来。比如：今天主要定三件事： 1. 订单状态是否要拆成独立状态机。 2. 库存扣减失败后是否允许重试。 3. 这版上线是否包含历史数据迁移。问题清楚了，参会的人才知道自己要贡献什么。否则会议很容易变成一个人讲，其他人礼貌地点头。三、参会人越多，不代表越稳很多人开会喜欢多拉几个人，觉得这样比较保险。但会议人数越多，成本越高，讨论也越容易发散。技术会议最好只叫和决策真正相关的人。需要拍板的人要在，需要提供关键信息的人要在，需要承担后续动作的人要在。只是“可能了解一下”的人，可以看会议纪要，不一定要坐完整场。保护团队的专注时间，也是技术负责人该做的事。四、没有结论的会议，要写清楚卡在哪里不是每个会议都能当场定结果。有时信息不够，有时风险没评估完，有时需要业务确认。这都正常。但会议不能以“再看看”结束。如果没有结论，至少要写清楚：现在卡在哪个问题。谁去补充信息。什么时候回来继续定。在结论出来前，哪些开发不能开始。否则会议开完以后，大家会各自按自己的理解往前走。这比不开会还危险。五、会议纪要不是流水账很多会议纪要写得像聊天记录。谁说了什么，谁补充了什么，谁提出一个疑问。看起来很完整，但真正有用的信息反而被埋住了。我更喜欢会议纪要只保留三类东西：结论：已经定下来的事情。 待确认：还没定、但会影响后续工作的事情。 动作项：谁在什么时候完成什么。这三类信息能让没参会的人快速知道状态，也能让后续追踪有依据。会议纪要不是为了证明开过会，而是为了让事情继续往前走。六、小结一个不浪费人的技术会议，不在于开得多正式。它应该有明确的问题，必要的人，能落地的结论，以及会后的动作。如果一个会开完以后，大家只是更累了，问题没有更清楚，责任没有更明确，那它就不是协作，而是集体消耗。技术负责人要敢于少开会，也要把必须开的会开得更像解决问题。本系列：上一篇：项目延期时，真正要复盘什么下一篇：新人培养，不能只靠“你先看代码”系列目录：一个技术负责人眼里的软件团队