前几天，我在公司内部做了一场技术分享。
聊的是提示词，这个被说烂了的东西。
这种主题乍一看，很容易让人先入为主。
好像又是一次AI工具课，讲讲各大模型怎么用，提示词怎么写，问法怎么调，最后再给大家几个模板，差不多就结束了。
由于我是一个AI高频使用者，用的多了就会有些自己的方法论。
同样都在用 AI，
有的人已经慢慢把它接进了自己的工作流里，越用越顺，越用越省力；
有的人还是停留在想到什么问什么，今天让它总结一下，明天让它改一段文案，后天又把差不多的问题从头讲一遍。
这中间差的，很多时候不是模型，也不是某一句提示词写得漂不漂亮。
真正拉开差距的，是你有没有开始认真梳理自己的工作。
所以这场分享聊的是怎么借着AI，把原来那些零散、重复、来回拉扯的工作，一点点整理成更清楚的流程。
这篇文章，我也想顺着那天的分享，把这些内容重新写下来。
一方面是给自己做个整理，另一方面也是想把里面一些有用的思路和技巧，传递给同样在用AI工作的人。
工作中是怎么使用AI的
先从一个最基础的问题说起，大家现在是怎么用AI的。
那天我开场先问了几个同学。
UI同学给我的回答很典型。她会把启动会的录屏丢给AI，让它先分析客户在品牌、设计方向上的一些想法，再从里面提一些灵感出来。
这个用法当然有帮助，但它有个很直接的问题，每一次都靠自然语言临场去问，AI输出的角度、颗粒度、格式，其实都不稳定。
开发这边的使用强度就更高了。
有同学已经把AI用到了一个项目里的很多个环节。
比如：
先把原型转成结构化文档，让它帮助自己快速理解需求，再把复杂模块、工作量大的模块挑出来，一步一步梳理细节，最后再用AI生成联调文档发给前端。
这里面有个经验我很认同，任务一长、环节一多的时候，最怕的就是让AI一次性吐出一大堆内容。
因为生成越多，错误往往也越多。
更稳的方式，是拆着来，一步一步推进，每一步都有人回看、有人改、再继续往下。
很多人对AI的使用方式，其实还是临时的。
如果只是偶尔做一次的事情，一问一答完全没问题。
但如果它会在工作里反复出现，出现三次、五次、十次，甚至每周都要来一遍，继续靠临场发挥去和AI对话，那就有点亏了。
应该把它沉淀成一个固定动作，甚至直接变成一个工具。
这个思路看起来简单，真正做起来会非常有力量。
售前
先说售前。
售前最典型的难点，是工作特别碎。
客户发来一堆聊天记录，需求文档写得粗，会议里又会讲很多发散想法，最后这些信息混在一起，既要快速理解，又要能沉成后面能用的物料。
这个环节如果只是一股脑丢给AI，让它总结一下，AI也能吐出点东西来，
但它会把很多无效信息一起吃进去，输出格式也不稳定。
这次它给你功能清单，下次它可能换一种结构，第三次又少掉关键的待确认事项。
这样的结果表面上看像是提效了，实操里反而很难真正接入下一步。
可一旦把这个动作做成规范，事情就会完全不同。
角色是什么，任务是什么，输入材料是什么，输出必须包含哪些部分，哪些内容可以整理，哪些地方要单独列出待客户确认...
这些规则先写清楚，后面每一次只要把新的聊天记录和会议内容扔进去，AI就会按同一套结构输出项目概述、端口角色、功能清单、待确认事项。
这样生成出来的，就是一份可以继续移交的工作物料。
产品
产品环节也是同样的问题。
很多产品工作，最耗脑力的地方，是信息链的连续性。
一个字段今天在后台叫这个名字，明天到了用户端换了另一个说法；一个订单流程上面改过一处，下面几个页面还是旧逻辑；前端和后端各自往前走，中间靠人工硬兜，改一轮、漏一轮。
那天大家都提到一个特别想解决的事情，改了某一个点之后，后面的相关环节能不能一起带出来，让AI帮忙把这种链式影响追下去。
这里需要的是一个能参与系统级整理的助手。
它得看懂页面之间的关系，看懂角色和状态的变化，看懂一个字段变了之后，哪些地方也要跟着变。
做到这一点，靠一句临时提问是远远不够的。
开发和测试
开发和测试这边，AI带来的变化会更直接。
开发最先感受到的是速度提升。
很多以前要一天半天的东西，现在十几分钟、几十分钟就能做出一个初版。
但速度拉上去之后，新的问题马上会冒出来。
代码质量，联调文档等等...
测试的压力也会跟着被放大，当开发一天能提十几个PR的时候，测试已经不太可能继续沿用过去那种等开发全部做完再统一提测的节奏了，它必须更早进入流程，甚至跟开发并行，一边开发一边测。
所以AI进入工作，从来不是单纯让某个岗位变快了那么简单。
它会逼着整条协作链路重新调整节奏。
这也是为什么提示词，不能只理解成一个提问技巧，它更像是一份工作说明书。
一次性的高质量回答，解决的是今天的问题。
一套可复用的提示词和工作流，解决的是未来很多次的问题。
怎么写提示词
这里分享一下自己搭提示词的思路。
Step1：搭骨架
搭骨架最先要明确的是，你现在到底在做什么事情，这件事的来源是什么，最后要产出什么。
先拿售前举例：
比如产品拿到售前移交过来的资料，要做需求梳理，那它产出的可能是角色清单、功能要求、业务流程图。
流程图是什么格式，角色之间用文字说明还是关系图，这些都属于第一步要想清楚的事情。
这一步想清楚之后，我更习惯先跟AI做开放式对话。
因为很多时候，自己也不知道自己到底想让 AI 产出什么内容，
或者不知道这个结果里面应该包含哪些部分，那就先对话。
让AI跟你一起把事情拆开，一步一步把流程问出来，列出来，再由人去校验。
在对话的过程中，你也许会越来越清晰，自己想要什么。
骨架文档的价值就在这，它逼着你把含糊的东西先想清楚。
售前可以通过这样提问，AI会返回清晰的文档，再由人去校验
Step2：补充细节
骨架有了之后，再往下加任务定义、输入输出说明、工作原则、输出校验、信息沉淀这些东西，提示词就慢慢成型了。
Step3：优化迭代
从一月份到现在，我一直在迭代这件事，有些框架还在改。
每次改完，我都会先自己跑一遍，看它有没有按我的意思理解。
因为AI理解人话这件事，很多时候没有我们想象得那么稳定。
你觉得自己表达得很清楚了，它可能还是会在某个点上拐弯。
你改上一句，它下面整段的意思都可能跟着变。
所以写提示词一定要有一点耐心。
我后来还做了一个很简单的小工具思路：
如果一开始不知道怎么写提示词，那就先别硬写，直接让AI来问。
问你岗位是什么，正在做什么，想产出什么。
你回答，它帮你整理。
再继续问，再继续补。
到最后，先搭出一个简单版的提示词框架。
这个方式我后来不只是用在售前，也用在简历筛选、需求分析、原型生成这些事情上。
思路都差不多，先让AI了解角色，再让它沿着这个角色的工作逻辑去提问，最后帮你把一个从零开始的模糊想法，整理成一份能用的工作说明。
写在最后
这场分享我自己也只是走到一个阶段，远远谈不上答案。
很多东西，还在继续试，继续改，继续踩坑。
AI发展得很快，工具一波接一波地变，模型也会一直更新。
但到最后，一个人能不能驾驭AI，最终还是会回到自己的思维能力上。
AI想不到的地方，就是想不到；看不见的边界，也不会意识到。
视野、判断、取舍、优先级...这些到最后，还是人的事。
AI负责提速。人负责定向。
这件事，至少到今天，依然没有变。
