知乎技术科普软文撰写

一、适用场景

本技能适用于以下场景：

• 用户提供甲方brief，要求撰写知乎平台的技术科普推广文章
• 需要在技术科普内容中自然植入产品卖点
• 文章面向技术从业者（开发者、产品经理、架构师等），需兼顾专业性和可读性
• 需要经历多轮细节审查迭代的软文写作任务

不适用于：纯品牌广告、小红书/公众号短文案、英文marketing copy。

二、核心工作流（7步）

Step 1：Brief解析

从甲方brief中提取5个维度：

1. 推广核心目标 — 甲方最想传递的1-3个核心信息（如"降本增效""智能路由"）
2. 文章要点 — 必须覆盖的内容模块（概念科普、产品功能、竞品差异等）
3. 产品数据锚点 — 可引用的硬数据（服务商数量、模型数量、降本比例等），这些数据是合规写作的基础
4. 禁忌要求 — 不能做什么（绝对化用语、贬低竞品、非指定链接等）
5. 参考结构 — 建议的文章结构（开头→中间→结尾），可根据达人风格调整

解析完成后，向用户确认理解是否准确，再进入下一步。

Step 2：多源产品信息采集

通过以下渠道交叉验证产品信息：

• 产品官网：获取官方功能描述、定价、核心卖点
• 科技媒体报道：InfoQ、CSDN、科技日报等，获取第三方视角和行业评价
• 技术社区文章：知乎专栏、博客园等，获取真实用户体验反馈
• 搜索引擎：补充产品最新动态、融资信息、竞品对比

采集重点：

• 核心数据（服务商数、模型数、评测模式等）必须与brief一致，以brief为准
• 产品的差异化定位（vs 竞品的核心区别）
• 可引用的具体功能细节和技术实现描述

Step 3：文风匹配

如果用户提供了样文（过去的知乎文章），必须仔细分析并匹配以下特征：

叙事结构模板：

场景痛点（真实故事引入）
→ 概念科普（类比拆解技术概念）
→ 产品植入（自然过渡到目标产品）
→ 收益总结（开发者视角的实际价值）
→ 评论区互动引导（开放式问题收尾）

文风要素清单：

| 要素 | 规范 | |------|------| | 人称 | 第一人称"我"，技术专家视角 | | 语气 | 聊天感，像跟朋友分享技术发现 | | 开头 | 从真实场景/故事切入（"最近我身边一个朋友…"） | | 类比 | 简单直白（导航、外卖等日常事物），拒绝复杂比喻 | | 数据呈现 | 善用表格做结构化对比 | | 段落节奏 | 长短句交替，避免公式化对仗 | | 产品过渡 | 从概念自然引出产品，不生硬植入 | | 收尾 | 回到开头故事形成闭环 + 引导评论互动 |

Step 4：撰写初稿

基于Brief结构 + 文风规范 + 采集素材，撰写全文。写作时同步执行首轮合规自审（见Step 5的检查清单），避免初稿就埋下合规隐患。

写作要点：

• 全文约5000-7000字，适合知乎长文阅读习惯
• 开头故事必须与文章主题强相关，不能为了讲故事而讲故事
• 概念科普部分要独立成章节，先把概念讲透，再引出产品
• 产品植入章节应在概念科普之后，建立在前文知识基础上
• 每个章节要有独立的信息增量，不重复讲同一个概念

Step 5：广告法合规审查（建议用子Agent）

完稿后，启动独立子Agent做5项合规检查：

1. 绝对化用语 — 全文搜索"最""第一""唯一""100%""根治""绝对""极致""领先"等词，逐一判断是否违规
   • 安全：描述技术逻辑中的"最优"（如"选择当前最优的服务商"）
   • 违规：宣称产品本身的绝对化定位（如"最好的平台"）
2. 虚假宣传 — 核对所有数据是否与brief一致，是否存在夸大效果或编造体验
3. 竞品贬低 — 检查是否有恶意贬低竞品的表述（客观对比≠贬低）
4. 敏感话题 — 确认不涉及政治、宗教、低俗等内容
5. 链接检查 — 确认只包含甲方指定的链接，无非指定品牌信息

发现问题立即修正，修正后再复查一遍。

Step 6：细节审查迭代（3+轮）

这是质量打磨的核心环节。每一轮按以下7项硬标准逐项检查：

6.1 Token/计费描述

• 必须写单价格式："每百万Token X元"
• 禁止："X块钱""X毛"等非专业表述
• 示例：✅ "每百万Token只要几块钱" ❌ "只要8毛钱"

6.2 痛点时效性

• 痛点必须是当下真实存在的问题
• 不写已经过时的行业问题（如"API格式不兼容"——现在服务商普遍兼容OpenAI/Anthropic格式）
• 痛点应聚焦当前真实困扰（如运维管理繁琐、计费规则复杂、多Key管理困难）

6.3 模型/产品举例

• 举例优先用独立厂商（如DeepSeek、GLM等），避免绑定特定云厂商
• 原因：用特定云厂商的模型会让文章看起来像该云的广告，削弱知乎科普文的可信度

6.4 用词准确性

• 禁止不严谨的表述："很直觉""显然""不难理解"
• 替代方案：用具体的逻辑推导替代主观判断词
• 示例：❌ "答案其实很直觉" ✅ "答案其实藏在XXX一个很巧妙的思路里"

6.5 竞品对比写法

• 用一句白话直接点出对方局限 + 自身优势
• 拒绝复杂比喻（如"万能遥控器vs智能电视系统"）
• 示例：✅ "OpenRouter只管把请求送出去，至于送到谁手里更合适，它不管；AI Ping则多了一步——帮你挑一个当下又快又便宜的"
• ❌ "OpenRouter更像万能遥控器——能切台，但不知道画质好不好；AI Ping更像自带画质监测的智能电视"

6.6 产品创新表述

• 用"巧妙""巧思"等表述凸显创新价值
• 禁止淡化创新的表述："不难想到""很直觉""其实很简单"
• 示例：✅ "答案其实藏在AI Ping一个很巧妙的思路里" ❌ "答案其实不难想到"

6.7 章节去重

• 不同章节不能重复讲同一个概念
• 后文提到前文概念时，应引用而非重复解释（如"前面第三节讲过这两个概念，这里重点说…"）
• 检查方法：通读全文，标记重复出现的概念，保留首次解释，后续改为引用

每轮审查后向用户汇报改动，然后进入下一轮，直到用户满意为止。

Step 7：文风活泼化

最后一轮整体润色，重点检查：

• 去公式化对仗：如果某段出现"A负责X，B负责Y"的工整结构，改为一段话串讲 + 具体场景
  • ❌ "模型路由负责'选对模型'。服务路由负责'选对通道'。"
  • ✅ "一个请求进来，先判断任务难度匹配模型，再在提供该模型的服务商里挑一条当前状态最好的通道。同一个模型，上午走A服务商，下午可能就切到B了。"
• 保持聊天感：读出来像在对朋友讲，不像在念稿
• 场景可感知：抽象概念要落地到具体场景（"上午走A服务商，下午切到B"比"动态切换"更生动）

三、禁忌事项

以下规则是硬约束，任何情况下不得违反：

1. 不使用绝对化用语（最、第一、唯一、100%、根治等），符合《广告法》
2. 不虚假宣传（数据以brief为准，不夸大效果，不编造体验）
3. 不恶意贬低竞品（客观对比可以，贬低不行）
4. 不涉及敏感话题（政治、宗教、低俗等）
5. 不插入非甲方指定的链接、二维码、其他品牌信息
6. 不抄袭、不洗稿，内容原创
7. 不在不同章节重复讲同一个概念

四、常见返工模式与修复策略

基于多次实战总结的高频返工模式和对应修复方案：

| 返工模式 | 根因 | 修复策略 | |---------|------|---------| | "这个比喻太复杂了" | AI倾向生成精巧但费解的类比 | 改用一句白话直说差异，不绕弯 | | "这里写得不够专业" | 计费/术语用了非行业写法 | 统一用token单价格式 | | "这个痛点已经不存在了" | AI的知识库滞后 | 替换为当下真实的行业痛点 | | "用XX的例子不合适" | 举例绑定了特定厂商 | 换成独立厂商的产品 | | "这段跟前文重复了" | AI在不同章节重复解释概念 | 后文改为引用前文，不再重复 | | "这段太生硬/像念稿" | 公式化对仗结构 | 改为串讲+具体场景 | | "这个词不准确" | 用了"直觉""显然"等主观词 | 换成具体逻辑推导 | | "创新点被淡化了" | 用了"不难想到"等弱化表述 | 改用"巧妙的思路"等凸显创新 |