企业官网建设流程全解析

4个月烧掉30亿Token，听起来像是个段子，但这是我真实踩过的一条路。从一个只会照着文档调接口的菜鸟程序员，到能同时维护50多个AI产品原型，我几乎把大模型API的每一种坑都踩了一遍。这段经历给我最大的收获，不是那批能跑但不算完美的产品，而是一整套把大模型能力变成真实可用产品的方法论，包括怎么选题、怎么估算成本、怎么写提示词、怎么控制模型输出质量。如果你现在正准备进入AI应用开发，或者手里已经有想法但不知道怎么落地，这篇文章能帮你省下至少两个月的试错成本。

当年我接到这个“批量做AI产品”的任务时，心里其实没底。技术栈很基础，预算倒是给得宽松，但要求在4个月内看到50个可演示的AI产品。这就逼着我必须找到一条足够轻、足够快、可复制的开发路线。整个过程走下来，我觉得最有价值的不是产品数量，而是那套被反复验证过的操作流程。下面我把这套流程拆开，从成本、选题、开发到排坑，一步步讲给你听。

1. 先把账算清楚：30亿Token到底烧在哪了

1.1 Token是个什么单位：30亿到底有多大

Token是大模型处理文本的最小单位。模型不是按字读文章，而是把一段话切成一个个小块，每个小块就是一个Token。在中文场景下，一个汉字通常会被切成1到2个Token，一个英文单词也差不多是1到2个Token。所以30亿Token大概对应十几亿到二十几亿字的文本量。这个量级意味着什么？一个人就算每分钟看300字，连续不睡也要看将近三个月。如果把这些Token打印成文档，能堆满一间不小的书房。

不过要注意，30亿Token并不是一次性花光的。大模型API的费用分为输入和输出，模型回答时每生成一个Token都是钱。对一个内容生成类产品来说，往往输出Token占比更高，因为用户只输入短短几个字，模型却要吐出一整篇文案或报告。我后来统计了一下，50多个产品里，真正把Token消耗撑起来的环节，集中在反复调试、批量生成和回归测试三块。

成本方面，以主流商用大模型的价目来看，每1百万Token的价格从几美元到几十美元不等。30亿Token如果全部用中间档模型，大约要烧掉大几千美元，折合人民币小几万元；如果某些环节图省事用了更高档模型，账单会明显往上走。这还只是API调用费用，没算开发时间和人工成本。对一个个人开发者来说，这个数字确实肉疼，但也说明一个问题：只要做产品时带着成本意识，30亿Token其实足够支撑50个原型反复折腾。

1.2 Token消耗的三大去向

我把Token消耗粗算过一笔账，用一张表能看得更清楚：

先说原型验证。很多人以为写一个AI产品就是调一次API，其实真正的Token消耗大头在“调”。我做一个会议纪要生成器，系统提示词改了5版，每版都要拿同一条会议记录跑3次以上看稳定性。一次测试跑10条样本，每条样本几百个Token，看起来不多，但50个产品乘下来，量就很离谱。

批量生成是另一个大头。很多内容型产品上线后要生成样本给用户预览，比如一次要生成20种风格的文案，或者把一个知识库里的100篇文章全部摘要一遍。这种任务一旦开跑，就会连续调用API几十上百次，输出Token像水一样流走。后来我学聪明了，凡是批量任务先拿10条做小规模试跑，确认输出格式没问题，再跑全量。

评测与回归是最容易被忽略的。产品做完了，你以为不烧钱了，但只要改过一次提示词，就必须把之前用过的测试集重新跑一遍，否则你不知道改动是变好了还是变差了。有一次我为了优化一个抽取产品的错误率，连续改了4版提示词，每版跑50条用例，一次回归就是几千Token。几个产品同时迭代的时候，这个消耗会成倍上涨。

1.3 预算控制：菜鸟最容易踩的成本坑

烧了30亿Token之后，我复盘出几个典型的成本坑，新手几乎都会踩一遍。

第一个坑是把上下文塞得太满。有人习惯把几十页资料全部塞进系统提示词，让模型“通读全文”。这样每一轮请求都要重复消化几万Token，钱烧得极快。更合理的方式是先做粗筛，只把和用户问题相关的段落传进去，或者在调用前先对资料做一次摘要，用摘要代替全文。

第二个坑是用高档模型处理简单任务。做文本分类、信息抽取、格式转换这类明确任务，完全可以用便宜的中小模型，没必要所有请求都上最强档。很多人觉得贵的就是好的，结果一个简单的“判断评论是正面还是负面”也走高档模型，成本直接翻了十几倍。正确的做法是给任务分档：需要创意、复杂推理的用高档；重复性劳动用低档。

第三个坑是完全没有缓存。同一个文档摘要，团队里几个人反复测试，同一段文本每天都跑一遍，白白浪费大量Token。我的解决方法是加了一层内存缓存，以输入文本的哈希值作为key，短时间内的相同请求直接返回历史结果，不回源调用API。实测下来能省20%到30%的Token。

第四个坑是把max_tokens设得过大。模型有时候会在回答末尾加一堆废话，或者由于参数设置不当，在内容没说完就结束。max_tokens设置过大会让模型倾向于生成更长回答，即使后半段没有实质内容，照样按Token收费。后来我统一给每个产品定了输出长度上限，超长内容拆成多段请求，而不是一次给足配额。

2. 50多个AI产品的选题逻辑：不是拍脑袋选出来的

2.1 产品分类：50个产品背后的底层能力复用

刚开始的时候我以为要做50个完全不同的技术方案，后来做着做着发现，大多数AI产品只是几个基础能力的排列组合。我把这些年做的AI产品归成三大类。

第一类是工具型，解决具体工作流里的一环。比如文档摘要、会议纪要生成、日志分析、SQL生成、代码解释、数据清洗。这类产品的特点是输入输出都比较结构化，用户能明确描述自己要什么，模型只需要把一项任务完成好。

第二类是内容生成型，辅助用户产出文稿。比如小红书标题、短视频脚本、周报月报、营销邮件、合同审查、行业调研报告。这类产品更适合让模型发挥“生成”能力，对创意和语气要求更高，但底层的提示词模板其实大同小异。

第三类是交互陪伴型，需要多轮对话能力。比如虚拟角色对话、英语口语陪练、模拟面试、考研问答机器人。这类产品的重点不在单次输出质量，而在怎么维护上下文、记住用户偏好、让对话连续不跑偏。

把50个产品放在这个框架里看，真正的新东西很少。会议纪要生成和文档摘要共享同一套抽取能力；小红书文案和短视频脚本共享同一套改写扩写能力；口语陪练和虚拟角色共享同一套多轮对话管理机制。所以第二个心得是：要做的不是50种技术，而是把四五种模型能力打磨成熟，然后用不同的提示词和外壳把它们包装成不同产品。

2.2 选题的三个标准：痛点、数据、模型能力

我选品时给自己定了三个硬标准，少一个都直接放弃。

第一个是真实痛点。这个痛点最好是你自己或者你身边人正在经历的，而不是你想象出来的。比如我自己每周要写周报，做周报生成器就有真实需求；身边同事老说会议纪要整理花时间，做会议纪要助手就有真实需求。判断标准很简单：如果产品做出来，你自己愿不愿意每天用？愿意，再往下走。

第二个是数据可得。你得有足够的真实输入做测试，否则产品只能靠编。做一个“小红书爆款标题生成器”，要准备几十条真实的热门笔记；做一个“合同风险审查助手”，要能找到脱敏后的合同样本。如果手里连10条像样的测试数据都没有，产品做出来也是空中楼阁，不好验证效果，也不好迭代提示词。

第三个是模型胜任。任务复杂度必须是目前大模型能稳定处理的边界之内。适合用模型做的事，通常是单步骤的信息处理，比如抽取、总结、改写、分类、多轮对话。不适合的事，是涉及复杂业务规则和系统联动的工作。举个例子，做“自动记账”这个产品听着很真实，但模型很难直接访问银行账单，还要理解各种消费类型和汇率规则，边界太多，不适合短周期开发。但把记账需求改成“从聊天记录中提取消费金额并分类”，就是一个很好的AI产品。

2.3 最小验证方案：10条测试输入决定去留

确定一个选题后，我不急着做界面，而是先用命令行脚本验证模型能力。方法特别简单：

先写一个不到50行的Python脚本，接收一段输入，调用大模型接口，把结果打印到终端。然后准备10到20条真实输入，一条一条跑，人工看结果。如果大部分输出质量达到“敢给别人看”的程度，就继续做；如果连一半都达不到，直接换题或者想办法把任务再拆简单一点。

我给自己定的标准是：10条测试里，至少有6条输出是可用的、没有明显错误的，这个选题才值得继续投入。如果可用率只有三四成，说明任务超出了模型的稳定能力，靠调提示词也很难救回来。与其死磕，不如换一个更细分的场景。比如“论文摘要生成”一开始效果总是不好，因为学术文本太专业，后来我把任务限定为“摘要前三段核心论点”，可用率立刻提了上来。

这种最小验证方案看起来很土，但效率极高。它没有经过任何UI层面的修饰，所有注意力都集中在“模型能不能完成核心任务”上。很多产品做到一半发现效果不行，原因就是一开始没做这个验证，把精力花在界面和流程上了。

3. 从0到1复刻整个套路：做一个AI产品的7个核心步骤

3.1 需求拆解与提示词工程

假设现在要做“会议纪要生成器”，输入是一段会议录音转写文本，输出是结构化的会议纪要。第一步不是写代码，而是把需求拆成三个部分：输入是什么、模型处理什么、输出是什么。

输入是一段未经整理的文本，可能还有语气词和重复内容。处理的本质是从文本中抽取信息，包括会议主题、关键讨论点、明确决策、行动项。输出是一份Markdown格式的结构化纪要，每一项都用列表呈现。

有了这个拆解，系统提示词就很容易写了。我给这类产品用的模板大致如下：

你是一名会议纪要助手。用户会提供一段会议记录或转写文本。请你输出： 1. 会议主题 2. 核心讨论点 3. 明确决策 4. 行动项（含负责人、截止时间，如果原文没有写，则标注“未提及”） 要求： - 使用简体中文 - 不要编造任何原文中没有的信息 - 使用Markdown列表，不要输出额外解释

这个模板看起来简单，但每一句都有用意。“不要编造”是为了解决幻觉问题，模型默认会补全信息，必须明确禁止。“使用Markdown列表”是为了方便解析，后面程序可以直接按标题和列表结构读取内容。“不要输出额外解释”则是为了省Token，很多模型会在正式结果前加一句“好的，这是你的纪要”，纯属浪费。

提示词工程的核心就是“把任务边界说清楚”。边界越清晰，模型的输出越稳定。我见过很多人写提示词只有一句“帮我总结一下”，效果自然不稳定。后来我习惯在提示词里加一个输出示例，也就是few-shot，把理想结果的样子给模型看一眼，成功率会提升很多。

3.2 接口调用与参数调优

写代码调用模型接口是整条链路里最枯燥但也最关键的一步。这里给一个最常见的Python调用示例，用的是通用HTTP方式，换成任何一个支持对话补全接口的模型都适用。

import requests def call_model(messages, model="the-model", temperature=0.3, max_tokens=800): url = "https://api.example.com/v1/chat/completions" headers = {"Authorization": "Bearer YOUR_API_KEY"} payload = { "model": model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } resp = requests.post(url, headers=headers, json=payload, timeout=60) if resp.status_code == 200: data = resp.json() return data["choices"][0]["message"]["content"] else: raise RuntimeError(f"API error {resp.status_code}: {resp.text}")

调用的时候，最重要的不是把接口调通，而是调参。temperature控制随机性，值越接近0，输出越稳定；越接近1，输出越有创造性。抽取、总结、格式转换这类任务，温度我一般设在0.1到0.3；写文案、创意标题这类任务，可以放到0.7到0.9。

max_tokens控制单次输出长度。我建议不要给太大，够用就行。很多时候输出内容过长，后半段质量会明显下滑，还增加成本。如果确实需要长内容，就拆成多个子任务分段生成，再拼起来。

还有两个参数，top_p和频率惩罚。top_p是做核采样，一般不会同时和temperature乱调。频率惩罚能减少重复词，但对稳定性要求高的任务，我通常不加。参数调优的原则是一次只动一个变量。如果发现输出不稳定，先把temperature降到0.1，跑10次看结果；如果还不稳，再检查提示词是否足够具体。

3.3 上下文管理与记忆机制

很多产品需要多轮对话，比如口语陪练、面试助手、虚拟角色。这类产品的核心问题不是“调用一次API”，而是怎么把上下文管理好，让模型记住前面说过的话。

大模型API普遍是一个无状态接口，每次调用都要把对话历史完整传过去。有一种偷懒做法是把所有历史消息全塞进messages里，但对话轮次一多，Token消耗会飙升，还会让模型注意力分散。我的做法是做一个滑动窗口，只保留最近10轮对话，更早的内容直接丢弃。

def build_messages(system_prompt, history, current_input, max_rounds=10): messages = [{"role": "system", "content": system_prompt}] for item in history[-max_rounds:]: messages.append({"role": "user", "content": item["user"]}) messages.append({"role": "assistant", "content": item["assistant"]}) messages.append({"role": "user", "content": current_input}) return messages

这个窗口逻辑写起来很简单，效果却很好。最近的话题被完整保留，模型能记住用户上一句在说什么，又不会因为几十轮历史让Token无限膨胀。10轮是一个经验值，具体产品可以自己调整；对话很短的产品保留5轮就够，话题经常跳转的产品可以留15轮。

如果要做长期记忆，我用的是另一招：把用户的核心偏好提炼成一段摘要，每次请求时塞进系统提示词。比如一个英语口语陪练产品，对话几十次之后，模型应该记住用户是程序员，喜欢聊技术话题，发音问题是th和r不分。每次对话结束后，我让模型输出一个“用户画像摘要”，下次请求时把这400字的摘要放在system prompt里，效果甚至比塞全部历史更好，因为摘要去掉了噪声。

3.4 从单次调用到多轮工作流

有些产品不能靠一次调用搞定，需要把一个大任务拆成多个小任务，一步步执行。比如做一个“行业调研报告生成器”，如果直接把“帮我写一份关于氢能源行业的报告”丢给模型，得到的往往是一篇泛泛而谈的空洞文章。但如果把任务拆成“生成大纲、逐章写作、整合编辑”三步，每一步的输出质量都会高很多。

我先让模型A生成一份大纲和关键词，再根据大纲逐节调用模型B生成内容，最后让模型C把各章节整合润色。每一步都可以用不同参数：大纲要求结构稳定，温度调低到0.2；正文写作要有一定发挥空间，温度设0.4；整合编辑又降回0.2。

def generate_report(topic): outline = call_model( [{"role": "system", "content": "你是一个报告规划者，输出Markdown大纲"}, {"role": "user", "content": f"请为'{topic}'生成报告大纲"}], temperature=0.2 ) sections = [] for section in parse_outline(outline): section_text = call_model( [{"role": "system", "content": "你是行业分析作者，按大纲写作，内容必须基于提供的资料"}, {"role": "user", "content": f"大纲章节：{section}\n请撰写正文"}], temperature=0.4 ) sections.append(section_text) final_report = call_model( [{"role": "system", "content": "你是编辑，把以下章节合并成完整报告"}, {"role": "user", "content": "\n\n".join(sections)}], temperature=0.2 ) return final_report

这套多轮工作流思路，后来我几乎用在了所有复杂产品上。核心原则是：一次调用只做一件事。任务拆得越细，每一步的输入越干净，输出就越可预期。也方便中途插入人工确认，比如报告大纲生成后，人可以先改一遍，再让模型按修订版写正文，避免一路错到底。

3.5 产品外壳的快速拼装

很多菜鸟听说要做一个AI产品，第一反应是先写好看的前端页面，把登录、注册、支付全做出来。这个思路顺序完全反了。在模型能力还没有验证之前，一切UI都是白搭。我一般用一个几十行的HTTP接口加一个极其简单的页面就把产品壳子搭起来了，能用就行。

这里用Python标准库实现一个最简POST接口，接收一段prompt，返回模型输出：

import http.server import json class Handler(http.server.BaseHTTPRequestHandler): def do_POST(self): length = int(self.headers.get("Content-Length")) body = json.loads(self.rfile.read(length)) result = call_model([{"role": "user", "content": body["prompt"]}]) response = json.dumps({"result": result}).encode() self.send_response(200) self.send_header("Content-Type", "application/json") self.end_headers() self.wfile.write(response) if __name__ == "__main__": server = http.server.HTTPServer(("0.0.0.0", 8000), Handler) server.serve_forever()

前端页面我也没有写过复杂组件，就用一个输入框、一个按钮、一个结果展示区，页面发一个fetch请求到上面这个接口。产品内部验证阶段，这种粗糙外壳反而更有优势，因为没有任何交互逻辑干扰你判断模型输出到底好不好。

当确认产品有效果之后，再把壳换漂亮。界面设计不是核心，核心是用户能通过什么方式触达模型能力。有的产品适合做成网页，有的适合做成浏览器插件，还有的只需要一个微信群机器人入口。前期别纠结形态，先让人用起来，再迭代。

3.6 自动化测试与评估

50多个产品同时迭代，如果每个输出都靠人一条条看，根本看不过来。我养成了一个习惯：每个产品都建一个测试集，用固定case验证提示词改动有没有把结果弄坏。

测试集是一个test.jsonl文件，每行一条JSON，包含id、输入文本、期望出现的关键词。比如会议纪要生成器的测试集，会检查输出里是否包含“行动项”“负责人”这类结构词，以及是否出现了原文中的关键决策。评估脚本简单粗暴，但非常有效：

import json def evaluate_case(case, output): for kw in case["expected_keywords"]: if kw not in output: return False return True with open("test.jsonl", encoding="utf-8") as f: cases = [json.loads(line) for line in f] passed = 0 for case in cases: output = call_model([{"role": "user", "content": case["input"]}]) if evaluate_case(case, output): passed += 1 print(f"pass rate: {passed / len(cases):.2%}")

这种规则评估不能判断“写得好不好”，只能判断“是否包含关键信息”。但对绝大多数工具型产品已经够了。如果某个产品对输出质量要求特别高，比如文案类产品，我再额外做人工抽检，每次改动后抽5条输出，自己扫一眼。

这套自动化回归的价值在于，提示词优化可以放心大胆试。改坏了，测试集马上告诉你；改好了，测试集也会告诉你。没有这层测试，很多人改提示词完全靠感觉，同一句话换个说法，模型输出就变了，根本分不清版本好坏。

3.7 上线与监控

产品上线之后，最怕的不是没人用，而是你不知道它什么时候悄悄烧钱、什么时候频繁报错。我给所有产品都加了一层最基础的日志，每次调用都记录一行JSON，包含时间、产品ID、输入Token数、输出Token数、延迟、状态码、结果截断。代码写得很简单：

import time import json def log_call(case_id, payload, result, token_used, latency): log_entry = { "time": time.time(), "case_id": case_id, "input_tokens": payload.get("input_tokens", 0), "output_tokens": payload.get("output_tokens", 0), "token_used": token_used, "latency": latency, "result_preview": result[:200] } with open("api_log.jsonl", "a", encoding="utf-8") as f: f.write(json.dumps(log_entry, ensure_ascii=False) + "\n")

每周我会统计一次日志，看几个指标：成功率、平均延迟、平均每次请求Token数、输出为空率。有一次账单异常上涨，我就是靠日志定位到是一个文档摘要产品在批量任务里把输入长度瓶颈拉到了满，单次请求消耗比平时高5倍。发现问题后调整了文本预处理逻辑，成本立刻降回来了。

监控不一定要上重型系统，一个日志文件加几个统计脚本，足够撑起50个产品的中小型项目。关键是所有产品统一走同一套日志格式，后期查问题会非常方便。

4. 50多个产品里沉淀的常见问题排查清单

4.1 输出不稳定：先降低随机性再看提示词

产品上线后最常收到用户反馈的就是“同样的输入，结果一会儿好一会儿差”。遇到这种问题，第一步先查temperature。如果设到0.7以上，输出波动是非常正常的，Creative类任务可以接受；但如果是抽取、分类、排版这类任务，必须把温度降到0.1到0.3之间。

降完温度还抖，再检查提示词有没有给出足够明确的输出约束。一个通用技巧是给模型一个输出样例，让它照着样子写。比如要JSON格式，就明确写“输出一个JSON对象，包含name、summary、category三个字段”。还可以要求模型先思考再回答，但有的时候这会增加输出长度，对简单任务反而不划算。

如果提示词已经很严格，输出还是偶尔出错，可以给同一请求加上重试机制。重试时建议临时把temperature再降一点，否则同样的错误可能再来一遍。注意重试要设置上限，最多两三次就够了，别让无效请求无限烧Token。

4.2 延迟高和超时：压输入、限输出、控制重试

AI产品最影响体验的问题之一是慢。请求一慢，用户就以为系统挂了。排查延迟高，我先看输入长度。如果每次请求都带着大段历史或冗长系统提示词，模型消化这些内容的耗时自然会变高。解决方法是把system prompt精简，历史只保留必要轮次，长文本先用摘要压缩再传入。

第二个看max_tokens。max_tokens设得越大，模型可能生成的回答越长，耗时也越长。给输出设一个合理上限，能明显降低响应时间。

第三个是网络和API本身的抖动。这种情况只能做超时重试。但重试要提防重复扣费：同一个请求因为超时重试了3次，结果3次都成功，最终可能造成三次计费。我的做法是在日志里记录request_id，重试前先查缓存，如果这个请求之前已经成功过，就直接返回上次结果，不再调用接口。这个机制看起来很小，却救回过不止一次因网络波动导致的重复扣费。

4.3 输出语言混乱：提示词约束加后处理兜底

很多产品跑着跑着，输出突然冒出英文、繁体或者一堆奇怪的标点。原因多半是模型在自由发挥，没有在提示词里限定语言。这件事最有效的解法是直接在系统提示词里写死：“全程使用简体中文，专业术语可保留英文缩写。”

光靠提示词还不够稳，因为模型可能偶尔违反规则。我在代码里加了一个后处理函数，先识别输出中是否有大段英文或异常字符，如果有，就把这轮输出标记为异常，重新调用一次模型。第二轮的输入里会附上第一轮输出和一句“请使用中文重新表达”。这个兜底方案能把语言混乱的比例压到极低。

还有一个细节：输出格式里的换行和列表符号，不同模型版本可能不一致。不要把解析逻辑写死成“必须是1. 2. 3.”，而是写成兼容“1.”、“-”、“*”的正则或解析器，省得模型版本一变，解析就崩。

4.4 价格飞涨：缓存、限上下文、合理选模型

前面讲成本时说过缓存，这里再具体一点。我给所有产品加了一层统一缓存层，以输入内容和系统提示词拼接后的哈希值作为key。如果相同请求在短时间内重复出现，直接返回缓存结果。在内容生成类产品里，有些用户会对同一个主题反复调整句子，其实很多请求是重复的，缓存能挡住很大一部分开销。

第二个控制手段是限制上下文长度。系统提示词尽量在2000Token以内，不需要的背景资料不要放。用户输入如果过长，先做一次抽取或摘要，只保留关键段落，而不是直接原样传给模型。

第三个是模型选择。同样的任务，用低档模型完成的效果可能只比高档模型差一点点，但价格差好几倍。我给每个产品单独配置了一个model字段，按任务复杂度灵活切换。简单抽取一律低档模型；上下文复杂或需要创意输出时，再临时切换到高档模型。这样才能让平均单次请求成本保持在一个合适区间。

4.5 幻觉问题：让模型只回答资料里有的事实

幻觉可能是AI产品最严重的质量问题。用户问一个产品问题，模型一本正经地编造了一个不存在的功能，这在客服问答、产品助手类场景里会导致极其糟糕的体验。

对付幻觉，最有效的手段不是提示词，而是给资料。凡是行为涉及事实陈述的产品，我都把相关资料放在系统提示词里，并在提示词开头写死：“只能基于以下资料回答问题，如果资料中没有提到，请直接说‘当前资料中未找到相关信息’，严禁编造。”这样模型就被限制在资料范围内，而不是整天复读自己的训练记忆。

如果某个问题连资料里都没有答案，模型应该明确说不知道，而不是给一个猜测。这一点用户其实是可以接受的，比收到错误答案好得多。我在验收测试时专门会加入这种“超纲问题”，检查模型是不是老老实实承认不知道。

5. 菜鸟到能批量做产品的三条真心话

5.1 别追求完美，先跑通闭环

我见过太多人做一个AI产品，先花两周设计页面，再做用户流程，最后才写调用API的代码。方向完全反了。正确的顺序是先让模型完成核心任务，再把这些能力包成一圈壳，最后才考虑界面漂不漂亮。

以周报生成器为例，第一版就是一个命令行脚本，用户把本周做的事粘进去，脚本输出一份周报草稿。虽然界面丑，但核心链路已经通了。然后我再加一个网页输入区，再考虑多模板、历史记录。整个过程中模型能力始终是重心，其他都是包装。

如果你追求第一版就完美，大概率第一版永远做不出来。大模型产品本身就是迭代驱动的产品，先跑通一个能用的小闭环，再在用户反馈里一点点改，反而更稳。

5.2 建立自己的提示词模板库

50多个产品做完，我最大的资产不是那批代码，而是一本提示词模板库。每个产品都会有对应的系统提示词、用户提示词、参数配置、输出格式、测试集和踩坑记录。我把它们按功能分类，比如摘要类、抽取类、改写类、扩写类、多轮对话类、代码生成类。

后续再做新产品，我基本不是从零写提示词，而是从库里选一个最接近的模板，改改场景和要求，再跑一轮回归测试。效率提高非常多。有一次同事让我做“客服话术优化助手”，我心里马上想到已有的“改写类模板”，只需要把语气约束从“正式”改成“亲切但不失专业”，然后补充几个客服场景的样例就算完成了。

这套模板库的价值在于，它把“直觉”变成可复用的资产。哪怕过了一个月，你再回头维护某个产品，翻开模板就能快速进入状态，不需要重新摸索。

5.3 学会让AI帮你造AI产品

最后这条真心话可能听起来有点套娃，但确实是真实经验。能支撑4个月做50个产品，很大一部分原因是把AI用在了造AI产品的每一个环节。写Python脚本、写系统提示词、构造测试用例、生成README，甚至排查报错，这些工作都可以先让模型做一版草稿，我再检查、修正、集成。

菜鸟和新手的区别不是能不能写出所有代码，而是能不能判断哪些代码是对的。一段由AI生成的代码，如果你根本看不懂它在干什么，就直接用，风险很高。我会先让模型把每段代码的作用写清楚，再在本地跑一遍，理解核心逻辑后才放进项目里。说白了就是用AI扩展自己的效率上限，但保留最终的判断权。

这个工作流在“批量做产品”的场景里尤其重要，因为人工精力是瓶颈。AI辅助能把从需求到原型的周期从两周压缩到两三天，而且还能保持稳定质量。当然，前提是自己要有基本的代码阅读能力，不是完全甩手给别人。

最后想多说一句掏心窝的话。这4个月烧掉的30亿Token，换来的不只是几十个能跑的产品，更重要的是一种判断力：拿到一个需求，我能在十分钟内说出哪部分交给模型、哪部分必须自己写代码、哪些坑必须提前躲开。这种判断力，才是以后做任何AI产品都值钱的底子。如果你也想走这条路，我的建议特别简单：别一上来就奔着50个产品去，先找一个最小、最真实的需求，烧上十万个Token试试水，把从提示词到API调用再到测试评估的闭环跑通。等你跑通了几个，就会发现自己对“AI能做什么、不能做什么”的理解，已经远超那些只刷文章从不动手的人了。