GLM-5.2 实测，中国模型真的到第一梯队了

大家好，这里是K姐。一个帮助你把AI真正用起来的女子。

过去，国产模型一发，大家安在各种模型头上的标签最好的不外乎开源第一，性价比第一。但是今天不一样了，智谱 GLM-5.2 模型一发，铺天盖地的消息涌来，开源模型已经和一流的闭源编模型旗鼓相当了，coding 方面，御三家该变成 GPT，Claude，智谱了。

GLM-5.2 现位居 Design Arena 第一，达到了 1360 的 Elo 分数。

BridgeBench BS（抗胡说测试）上排名 #1，得分 100.0，在推理能力上排名 #1，得分 42.8。

GLM-5.2 在 Code Arena: Frontend 中也排名第 2，比 Claude Opus 4.7 (Thinking) 高出 29 分，仅落后于 Fable 5!

不过，不是美国人的我，想问问各位友友们 Claude Fable5 现在在哪里发财呢？我咋用不到呢！

全世界最强的编程模型被禁令关停，不让大家使用，GLM-5.2 却把同一量级的能力开源给了所有人。但是我还是准备自己来测一测 GLM-5.2，我不是信不过这些榜单，而是感觉自己测一次，一来能确定模型好不好用，二来能确定模型适不适合自己，毕竟每个人的使用场景不一样。我准备从 coding 和日常任务这两方面测试，好，多的不说，测试里见真章~

GLM-5.2实测

Case 1 1M 上下文测试

这次 GLM-5.2 比较重要的改变就是支持了 1M 上下文，所以肯定要测一下的！直接让 GLM-5.2 出一个APP 设计稿试试。

提示词：根据文档需求，完成K姐食堂APP的设计。K姐食堂外卖点餐 App 产品需求文档 PRD版本：V1.0文档状态：初稿产品名称：K姐食堂产品类型：外卖点餐 App目标平台：iOS、Android、H5、小程序可扩展目标阶段：MVP 到正式上线撰写日期：2026-06-171. 文档说明
1.1 文档目的
本文档用于定义「K姐食堂」外卖点餐 App 的产品定位、业务目标、用户角色、核心流程、功能需求、业务规则、数据指标、后台管理能力、非功能需求、验收标准和版本规划。
文档面向产品、设计、研发、测试、运营、商家管理、配送管理等角色，作为后续原型设计、技术方案拆解、研发排期、测试用例编写和上线验收的统一依据。
1.2 产品一句话
K姐食堂是一款面向工作日高频用餐人群的外卖点餐 App，主打「好选、快下单、准时送、容易复购」，帮助用户用最少步骤完成日常工作餐、轻食、套餐和饮品点单。
1.3 版本范围
V1.0 聚焦外卖点餐核心闭环，包括用户登录、定位选址、店铺浏览、菜品点选、购物车、订单确认、支付、商家接单、配送履约、订单追踪、取消退款、评价、复购和基础后台。
V1.0 不做复杂内容社区、直播、拼团、会员等级体系、复杂推荐算法、多人点餐、预制菜商城和重营销玩法，优先保证点餐链路稳定、订单状态准确、履约可追踪、售后可处理。
2. 产品背景
2.1 市场背景
外卖已经成为工作日午餐、晚餐、加班餐和临时补给的高频场景。用户对外卖平台的基础诉求并不复杂：想快点找到能吃的、价格清楚、配送时间靠谱、出问题能处理、下次还能快速复购。
但在实际使用中，很多点餐体验被过度复杂的信息流、过多营销入口、菜品信息不清晰、配送承诺不稳定、售后入口隐藏等问题打断。用户不是每次都想逛平台，很多时候只是想在 1 分钟内解决「今天吃什么」。
K姐食堂的机会点不在于做一个大而全的综合外卖平台，而在于先把一个高频、稳定、可控的日常点餐场景做好。比如办公园区、学校周边、社区楼宇、企业餐补场景、单品牌多门店食堂、连锁轻食餐饮等。
2.2 用户痛点
用户侧常见痛点包括：
1. 选择成本高。首页信息太杂，活动、广告、榜单、推荐混在一起，用户不知道从哪里开始。2. 菜品信息不清楚。图片和实物差异大，规格、分量、辣度、加料、包装费、配送费不透明。3. 午高峰体验不稳定。商家接单慢、出餐慢、骑手等待时间长，用户无法判断到底卡在哪一步。4. 复购不方便。用户常吃的套餐和店铺没有被突出，历史订单复购还要重新确认一堆选项。5. 售后流程麻烦。餐品缺漏、送错、洒漏、超时、无法联系骑手时，用户不知道怎么快速处理。6. 优惠理解成本高。满减、券、配送费、包装费叠加后，用户不清楚为什么实付价变化。
商家侧痛点包括：
1. 高峰期订单集中，容易漏接、错单、出餐状态不同步。2. 菜品库存和上下架更新不及时，用户下单后才发现缺货。3. 退款、改菜、催单、备注处理缺少标准流程。4. 店铺经营数据不清楚，难以判断热销菜、复购菜、差评原因和高峰压力。
运营侧痛点包括：
1. 异常订单无法及时发现，客服被动接投诉。2. 不同商家的接单、出餐、售后效率无法量化。3. 优惠活动缺少配置和效果追踪。4. 用户留存、复购、退款、超时等核心指标分散。
2.3 产品机会
K姐食堂应从「点餐效率」和「履约确定性」两个方向切入：
1. 首页不做复杂内容流，优先呈现附近可下单店铺、常点套餐、今日推荐和搜索。2. 店铺页强化菜单结构、规格选择、菜品状态和购物车金额透明。3. 订单状态精细化，明确展示商家接单、备餐、骑手取餐、配送中、已送达等节点。4. 复购入口前置，让高频用户可以用更少步骤完成再次下单。5. 后台可配置店铺、菜品、优惠、配送、售后和异常订单处理规则。
3. 产品定位与目标
3.1 产品定位
K姐食堂定位为高频日常点餐工具，不做泛娱乐平台。产品体验应偏清爽、直接、稳定，减少不必要的打扰，让用户知道「今天有什么能吃」「多久能送到」「多少钱」「出了问题找谁」。
产品关键词：- 高频- 工作餐- 快速下单- 准时配送- 套餐化- 易复购- 可追踪- 售后明确
3.2 目标用户
核心用户：
1. 办公楼白领。工作日午餐和晚餐需求稳定，重视送达时间、性价比和复购效率。2. 学生群体。价格敏感，偏好套餐、饮品、夜宵和多人宿舍配送。3. 社区居民。晚餐、周末和临时加餐需求较多，重视口味、商家稳定性和配送范围。4. 企业团餐/餐补用户。下单时间集中，需要发票、企业账户、固定地址和批量订单能力，V1.0 只预留扩展。
次级用户：
1. 商家店员。负责接单、备餐、库存、缺货处理和售后确认。2. 骑手。负责取餐、配送、异常上报和联系用户。3. 平台运营。负责订单监控、活动配置、商家管理、投诉处理和数据分析。
3.3 产品目标
用户体验目标：
1. 新用户从打开 App 到完成首单支付，核心路径不超过 5 分钟。2. 老用户通过「再来一单」完成复购，理想路径不超过 30 秒。3. 用户能在订单详情页清楚看到当前订单卡在哪个履约节点。4. 用户在 3 次点击内找到取消订单、申请退款、联系客服或催单入口。
业务目标：
1. 完成外卖下单、支付、接单、备餐、配送、送达、评价的闭环。2. 支持单店、单商圈试点上线，后续扩展到多门店。3. 支持基础优惠配置，提高首单转化和复购。4. 建立订单、履约、售后、商家表现等基础数据看板。
技术目标：
1. 订单状态一致、可追溯，不出现用户端、商家端、后台状态不一致。2. 支付回调、退款、取消订单等关键链路具备幂等处理。3. 高峰期具备基础抗压能力，订单提交和商家接单不能因并发明显异常。4. 支持后续扩展多门店、多城市、企业餐补、会员和智能推荐。
4. 核心指标
4.1 用户转化指标- 首页访问人数- 店铺页访问人数- 菜品加购率- 购物车提交率- 订单支付成功率- 首单转化率- 复购率- 下单路径平均耗时
4.2 履约指标- 商家平均接单时长- 商家平均出餐时长- 骑手平均到店时长- 骑手平均配送时长- 平均送达时长- 超时订单率- 取消订单率- 缺货订单率- 异常订单率
4.3 经营指标- GMV- 支付订单数- 客单价- 实付金额- 优惠补贴金额- 配送费收入- 包装费收入- 退款金额- 商家销售排行- 菜品销售排行
4.4 体验指标- 用户评分- 菜品评分- 店铺评分- 配送评分- 投诉率- 售后处理时长- 退款通过率- 差评原因分布
5. 用户画像与场景
5.1 用户画像一：午餐高频白领
姓名：小林年龄：27 岁场景：工作日 11:30 前后点午餐特征：时间紧、选择困难、常点固定套餐诉求：快速下单、准时送达、价格稳定、可以复购典型行为：打开 App 后看常点店铺或今日套餐，确认地址后直接下单。
5.2 用户画像二：加班晚餐用户
姓名：阿杰年龄：31 岁场景：晚上 19:00 后加班点餐特征：更关心配送范围和出餐速度诉求：能快速知道哪些店还营业，预计多久送到典型行为：按「还在营业」「最快送达」「热销套餐」筛选。
5.3 用户画像三：价格敏感学生
姓名：小雨年龄：20 岁场景：午饭、夜宵、饮品特征：关注优惠、满减、配送费、起送价诉求：实付价清楚，优惠容易理解典型行为：先看活动套餐和新人券，再决定是否下单。
5.4 用户画像四：商家店员
姓名：王姐年龄：38 岁场景：午高峰集中接单特征：操作时间有限，不能频繁切换复杂页面诉求：订单提醒明显、备注清楚、缺货可快速处理典型行为：听到新订单提示后接单，按顺序备餐，出餐后标记待取餐。
5.5 用户画像五：平台运营
姓名：Mia年龄：29 岁场景：监控平台订单和异常特征：需要快速发现超时、退款、差评和商家异常诉求：有清晰后台、可筛选、可导出、可处理典型行为：查看当日订单看板，处理异常池中的超时订单和投诉。
6. 总体业务流程
6.1 用户下单主流程
1. 用户打开 K姐食堂。2. 系统获取定位或用户选择收货地址。3. 首页展示可配送店铺、推荐套餐和分类入口。4. 用户进入店铺页。5. 用户选择菜品、规格、数量，加购到购物车。6. 用户进入订单确认页。7. 系统校验配送地址、营业状态、库存、起送价、优惠和配送费。8. 用户选择优惠券、餐具数量、备注和支付方式。9. 用户提交订单并完成支付。10. 系统创建支付订单，等待支付回调。11. 支付成功后订单进入待商家接单状态。12. 商家接单后进入备餐中。13. 商家出餐后进入待骑手取餐。14. 骑手取餐后进入配送中。15. 骑手确认送达后进入已送达。16. 用户确认收餐或系统自动完成。17. 用户评价订单。
6.2 复购流程
1. 用户进入「我的」或首页「常点」。2. 用户选择历史订单。3. 点击「再来一单」。4. 系统校验店铺营业状态、菜品是否在售、规格是否可用、库存是否充足。5. 若全部可用，恢复购物车并进入订单确认页。6. 若部分菜品不可用，提示用户删除或替换。7. 用户确认后支付下单。
6.3 取消订单流程
1. 待支付订单：用户可直接取消，无需退款。2. 已支付但商家未接单：用户可无责取消，系统自动退款。3. 商家已接单但未出餐：用户申请取消，商家确认后退款。4. 商家已出餐或骑手已取餐：原则上不支持无责取消，需客服介入。5. 已送达订单：不支持取消，只能发起售后。
6.4 缺货处理流程
1. 商家接单前发现菜品缺货。2. 商家可选择拒单并填写原因，或发起改菜/部分退款申请。3. 用户收到缺货提示。4. 用户可选择接受替换、删除缺货菜品或取消订单。5. 若用户超时未处理，系统按配置自动取消或转人工。
6.5 配送异常流程
配送异常包括骑手到店等待过久、用户联系不上、地址错误、餐品损坏、天气或交通原因导致超时。
处理原则：
1. 骑手必须选择异常类型并填写说明。2. 用户端展示简化后的异常提示。3. 后台异常池生成记录。4. 运营可联系用户、骑手或商家处理。5. 异常处理结果需要同步到订单详情。
7. 产品信息架构
7.1 用户端信息架构
一级导航：- 首页- 订单- 我的
首页模块：- 地址栏- 搜索- 分类入口- 今日推荐- 常点菜品- 附近店铺- 优惠活动
订单模块：- 当前订单- 历史订单- 待评价订单- 售后订单
我的模块：- 用户信息- 优惠券- 地址管理- 收藏店铺- 客服中心- 发票- 设置
7.2 商家端信息架构
一级导航：- 工作台- 订单- 菜品- 店铺- 数据
工作台模块：- 营业状态- 今日订单- 待接单- 备餐中- 待出餐- 异常提醒
菜品模块：- 菜品列表- 分类管理- 规格管理- 库存管理- 上下架
7.3 后台信息架构
一级导航：- 数据看板- 订单管理- 用户管理- 商家管理- 骑手管理- 菜品管理- 优惠管理- 售后管理- 系统配置
8. 用户端功能需求
8.1 登录注册
8.1.1 功能说明
用户通过手机号验证码登录。首次登录自动注册账号。V1.0 不强制用户设置密码，不做第三方账号绑定，可预留微信、支付宝、Apple 登录扩展。
8.1.2 需求详情
1. 用户输入手机号。2. 点击获取验证码。3. 系统校验手机号格式。4. 验证码发送成功后按钮进入倒计时。5. 用户输入验证码并提交。6. 验证成功后进入首页。7. 若用户为新用户，系统创建用户账号。8. 若用户未同意用户协议和隐私政策，不允许登录。
8.1.3 异常处理- 手机号格式错误：提示「请输入正确的手机号」。- 验证码错误：提示「验证码不正确，请重新输入」。- 验证码过期：提示「验证码已过期，请重新获取」。- 短信发送过于频繁：提示「操作太频繁，请稍后再试」。
8.2 地址与定位
8.2.1 功能说明
地址是外卖履约的基础。系统需要支持自动定位、手动选择地址、地址新增、编辑、删除和默认地址设置。
8.2.2 需求详情
1. 用户首次进入 App，系统请求定位授权。2. 用户允许后，首页显示当前定位附近地址。3. 用户拒绝定位时，可手动搜索或新增地址。4. 地址字段包括联系人、手机号、性别称呼、所在地区、详细地址、门牌号、标签。5. 地址标签支持家、公司、学校、自定义。6. 用户可设置默认地址。7. 下单时必须选择可配送地址。
8.2.3 配送范围校验
进入店铺页和提交订单时都需要校验地址是否在配送范围内。
若不在配送范围内：- 店铺卡片显示「超出配送范围」。- 店铺页禁止加购或禁止结算。- 订单确认页提示用户更换地址。
8.3 首页
8.3.1 功能定位
首页用于帮助用户快速进入点餐状态，不承担复杂内容消费功能。首页优先解决「附近有什么」「今天推荐什么」「我常吃什么」「最快多久送到」。
8.3.2 页面元素
1. 顶部地址栏：展示当前配送地址，点击可切换。2. 搜索框：支持搜索店铺名、菜品名、关键词。3. 分类入口：工作餐、轻食、面饭、饮品、夜宵、早餐。4. 今日推荐：运营配置的套餐或店铺。5. 常点菜品：基于历史订单展示。6. 附近店铺列表：按综合排序展示。7. 优惠标签：展示新人券、满减、配送券等。
8.3.3 店铺卡片字段- 店铺名称- 店铺头像或封面- 评分- 月售- 人均价格- 起送价- 配送费- 预计送达时间- 距离- 优惠标签- 营业状态
8.3.4 排序规则
默认综合排序可综合以下因素：
1. 是否营业。2. 是否可配送当前地址。3. 预计送达时间。4. 店铺评分。5. 月销量。6. 用户历史偏好。7. 运营推荐权重。
V1.0 可采用规则排序，不做复杂机器学习推荐。
8.4 搜索
8.4.1 功能说明
用户可搜索店铺、菜品和关键词。搜索结果需要明确区分店铺结果和菜品结果。
8.4.2 搜索入口- 首页搜索框- 店铺页菜单搜索
8.4.3 搜索结果
搜索结果包括：
1. 店铺列表。2. 菜品列表。3. 无结果页。4. 历史搜索词。5. 热门搜索词。
8.4.4 无结果处理
当无搜索结果时，展示：- 「没有找到相关结果」- 推荐用户换个关键词- 展示附近热销店铺或分类入口
8.5 店铺页
8.5.1 功能定位
店铺页是用户决策和点餐的核心页面，应让用户清楚看到店铺是否可下单、配送多久、有哪些菜、价格如何、菜品是否可选、购物车金额是否达起送。
8.5.2 页面结构
1. 店铺头部：- 店铺封面- 店铺名称- 评分- 月售- 公告- 配送时间- 起送价- 配送费2. 标签页：- 点餐- 评价- 商家信息3. 菜品分类侧栏。4. 菜品列表。5. 底部购物车。
8.5.3 菜品信息
菜品字段包括：- 菜品图片- 菜品名称- 菜品描述- 月售- 好评率- 价格- 原价- 规格- 库存状态- 推荐标签
8.5.4 菜品状态
菜品状态包括：- 正常可售- 已售罄- 已下架- 非当前时间段供应
不可售菜品可展示但不可加购，按钮置灰并说明原因。
8.6 菜品规格
8.6.1 功能说明
部分菜品存在规格选择，如份量、辣度、主食、加料、饮品温度等。用户点击加购时若存在规格，弹出规格选择面板。
8.6.2 规格类型
常见规格包括：- 份量：小份、标准、大份。- 辣度：不辣、微辣、中辣、特辣。- 主食：米饭、面、粉。- 加料：鸡蛋、肉片、蔬菜、芝士。- 饮品：热、常温、冰。
8.6.3 选择规则
规格可配置为单选或多选。必选规格未选择时，不允许加入购物车。规格加价需要实时计入菜品价格。
8.7 购物车
8.7.1 功能说明
购物车用于展示当前店铺已选菜品、数量、规格、价格、优惠提示和起送差额。
8.7.2 需求详情
1. 用户可增加或减少菜品数量。2. 用户可清空购物车。3. 用户可修改已选菜品规格。4. 购物车实时计算菜品总价。5. 未达到起送价时，提示「还差 X 元起送」。6. 达到起送价后，按钮变为「去结算」。7. 同一订单只支持同一店铺菜品，V1.0 不做跨店铺购物车。
8.7.3 价格展示
购物车展示金额包括：- 菜品金额- 规格加价- 包装费- 配送费预估- 优惠预估- 预计实付
完整金额以订单确认页为准。
8.8 订单确认页
8.8.1 功能说明
订单确认页是支付前最终确认页面，需要完成配送地址、送达时间、菜品明细、优惠、备注、餐具、费用和支付方式确认。
8.8.2 页面字段- 配送地址- 联系人和手机号- 预计送达时间- 店铺名称- 菜品明细- 包装费- 配送费- 优惠券- 备注- 餐具数量- 支付方式- 费用明细- 提交订单按钮
8.8.3 下单前校验
提交订单前需要校验：
1. 用户是否登录。2. 地址是否完整。3. 地址是否在配送范围。4. 店铺是否营业。5. 菜品是否仍在售。6. 库存是否充足。7. 金额是否满足起送价。8. 优惠券是否可用。9. 支付方式是否可用。
若校验失败，系统需明确提示失败原因，并引导用户修改。
8.9 支付
8.9.1 支付方式
V1.0 支持微信支付和支付宝支付，可预留余额支付、企业餐补支付。
8.9.2 支付流程
1. 用户点击提交订单。2. 系统创建订单，状态为待支付。3. 系统拉起支付。4. 用户完成支付。5. 支付渠道回调。6. 系统更新订单为待商家接单。7. 用户端展示支付成功页或订单详情页。
8.9.3 支付异常- 用户取消支付：订单保留待支付状态，可重新支付。- 支付失败：提示失败原因，支持重新支付。- 支付成功但页面未返回：用户进入订单页时需根据服务端状态展示。- 支付回调重复：服务端需幂等处理。
8.10 订单列表
8.10.1 功能说明
订单列表展示用户当前订单和历史订单，支持查看详情、再来一单、评价、退款和联系客服。
8.10.2 订单分类- 全部- 进行中- 待评价- 退款/售后
8.10.3 订单卡片字段- 店铺名称- 订单状态- 下单时间- 菜品摘要- 实付金额- 操作按钮
操作按钮根据状态变化：- 待支付：去支付、取消订单- 待商家接单：取消订单、联系商家- 备餐中：催单、联系商家- 配送中：联系骑手、查看配送- 已完成：再来一单、评价、申请售后- 已取消：再来一单
8.11 订单详情
8.11.1 功能说明
订单详情页用于展示履约进度和订单信息，是用户下单后的核心查看页面。
8.11.2 页面模块
1. 订单状态区：- 当前状态- 预计送达时间- 状态说明2. 履约时间线：- 订单已提交- 商家已接单- 商家备餐中- 骑手已取餐- 配送中- 已送达3. 配送信息：- 骑手姓名- 骑手电话- 当前位置，V1.0 可不做实时地图，预留4. 商家信息：- 商家电话- 商家地址5. 菜品明细。6. 费用明细。7. 订单编号。8. 售后入口。
8.12 评价
8.12.1 功能说明
用户可对已完成订单进行评价，评价对象包括整体订单、菜品、配送和商家。
8.12.2 评价内容- 星级评分- 文字评价- 图片上传- 匿名评价- 推荐标签
8.12.3 评价规则
1. 已完成订单可评价。2. 每个订单只允许评价一次。3. 评价提交后可在一定时间内追加，不支持随意修改。4. 涉及敏感词、辱骂、隐私的信息进入审核。
8.13 售后
8.13.1 售后类型- 取消订单- 申请退款- 部分退款- 餐品缺漏- 餐品损坏- 送错餐- 配送超时- 未收到餐
8.13.2 售后流程
1. 用户选择售后原因。2. 用户填写说明并上传凭证。3. 系统判断是否自动处理。4. 自动处理失败或金额较高时进入人工审核。5. 商家或平台运营处理。6. 用户收到处理结果。7. 若退款通过，原路退回支付账户。
8.13.3 自动退款规则
V1.0 可先支持有限自动退款场景：- 商家未接单时用户取消。- 商家超时未接单。- 店铺主动拒单。- 支付后库存校验失败。
其他场景进入人工审核。
8.14 优惠券
8.14.1 优惠类型- 新人券- 满减券- 配送券- 店铺券- 平台券
8.14.2 使用规则
1. 新人券仅限首单可用。2. 满减券需达到指定门槛。3. 配送券只抵扣配送费。4. 店铺券仅限指定店铺。5. 平台券适用于所有参与活动店铺。6. 单笔订单默认只可使用一张满减类优惠券。7. 配送券可与满减券叠加，具体由后台配置。
8.14.3 展示规则
订单确认页应展示可用券和不可用券。不可用券需要说明原因，例如未达到门槛、不适用该店铺、已过期、不可与当前活动叠加。
9. 商家端功能需求
9.1 商家登录
商家通过账号密码或手机号验证码登录。账号由平台后台创建并分配权限。
商家账号角色包括：- 店主- 店长- 店员
不同角色权限不同。V1.0 可先实现基础权限，店员可处理订单和菜品库存，店主可查看数据和管理店铺信息。
9.2 商家工作台
工作台用于高峰期快速处理订单。
展示内容：- 当前营业状态- 今日订单数- 今日销售额- 待接单数量- 备餐中数量- 待骑手取餐数量- 异常订单数量
核心操作：- 开始营业- 暂停营业- 接单- 拒单- 标记出餐- 联系用户- 联系骑手
9.3 订单管理
9.3.1 订单状态
商家端订单状态包括：- 新订单- 已接单- 备餐中- 待取餐- 已取餐- 已完成- 已取消- 退款中
9.3.2 新订单提醒
新订单需有明显提醒：- 声音提醒- 弹窗提醒- 列表置顶- 未处理数量角标
商家未在配置时间内处理时，后台生成超时提醒。
9.3.3 接单规则
商家可接单或拒单。
拒单必须选择原因：- 菜品缺货- 已打烊- 配送异常- 订单备注无法满足- 其他原因
拒单后订单取消并退款，拒单原因同步给用户和后台。
9.4 菜品管理
9.4.1 菜品字段- 菜品名称- 菜品分类- 菜品图片- 菜品描述- 售价- 原价- 库存- 包装费- 规格- 是否推荐- 上架状态- 售卖时间
9.4.2 菜品操作- 新增菜品- 编辑菜品- 删除菜品- 上架- 下架- 设置售罄- 恢复库存- 调整排序
9.4.3 库存规则
1. 库存为 0 时，菜品自动显示售罄。2. 用户下单支付成功后扣减库存。3. 订单取消或退款时是否返还库存由订单状态决定。4. 商家可手动设置今日售罄。
9.5 店铺管理
店铺信息包括：- 店铺名称- 店铺 Logo- 店铺封面- 店铺公告- 营业时间- 配送范围- 起送价- 配送费规则- 包装费规则- 联系电话- 店铺地址
营业状态包括：- 营业中- 休息中- 暂停接单- 已打烊
暂停接单时，用户可浏览店铺和菜品，但不能下单。
9.6 商家数据
商家端展示基础经营数据：- 今日订单数- 今日营业额- 今日退款数- 热销菜品- 差评订单- 平均接单时长- 平均出餐时长
V1.0 只做基础展示，不做复杂经营分析。
10. 骑手端功能需求
10.1 骑手登录
骑手账号由平台后台创建，骑手通过手机号验证码登录。骑手需具备实名信息和联系方式，V1.0 可由后台录入。
10.2 配送任务
骑手端任务列表包括：- 待取餐- 配送中- 已完成- 异常任务
任务卡片展示：- 店铺名称- 店铺地址- 用户地址- 预计送达时间- 订单号- 联系商家- 联系用户
10.3 状态操作
骑手可执行以下状态操作：
1. 到店。2. 已取餐。3. 配送中。4. 已送达。5. 上报异常。
状态变更需同步到用户端、商家端和后台。
10.4 异常上报
异常类型包括：- 商家未出餐- 用户联系不上- 地址错误- 餐品损坏- 交通原因- 天气原因- 无法进入小区或楼宇
骑手上报异常后，后台异常池生成记录，运营可介入处理。
11. 运营后台功能需求
11.1 数据看板
后台首页展示平台整体经营数据：- 今日 GMV- 今日支付订单数- 今日退款订单数- 今日活跃用户- 当前进行中订单- 当前异常订单- 超时订单率- 平均配送时长
数据支持按日期筛选，V1.0 支持今日、昨日、近 7 天、近 30 天。
11.2 订单管理
订单管理支持查看、筛选、导出和处理订单。
筛选条件：- 订单编号- 用户手机号- 店铺名称- 骑手名称- 订单状态- 支付状态- 售后状态- 下单时间
订单详情展示：- 用户信息- 商家信息- 骑手信息- 菜品明细- 费用明细- 支付信息- 状态流转日志- 售后记录- 操作日志
后台可执行：- 取消订单- 发起退款- 标记异常- 添加备注- 联系用户- 联系商家- 联系骑手
11.3 用户管理
用户管理字段：- 用户 ID- 手机号- 昵称- 注册时间- 最近下单时间- 订单数- 支付金额- 用户状态
后台操作：- 查看用户详情- 查看用户订单- 禁用用户- 解禁用户- 添加运营备注
手机号展示需脱敏，只有具备权限的角色可查看完整手机号。
11.4 商家管理
商家管理字段：- 店铺 ID- 店铺名称- 联系人- 联系电话- 地址- 营业状态- 审核状态- 订单数- 评分
后台操作：- 新增店铺- 编辑店铺- 审核店铺- 设置营业状态- 配置配送范围- 配置费用规则- 查看经营数据
11.5 骑手管理
骑手管理字段：- 骑手 ID- 姓名- 手机号- 状态- 今日配送单数- 平均配送时长- 投诉次数
后台操作：- 新增骑手- 编辑骑手- 启用/停用- 分配配送区域- 查看配送记录
11.6 优惠管理
后台支持创建优惠券。
优惠券字段：- 优惠券名称- 优惠类型- 面额- 使用门槛- 适用店铺- 发放数量- 每人限领数量- 有效期- 是否可叠加- 使用说明
优惠券状态：- 未开始- 进行中- 已结束- 已停用
11.7 售后管理
售后管理用于处理退款、投诉和异常订单。
售后单字段：- 售后单号- 订单号- 用户- 店铺- 售后类型- 申请金额- 申请原因- 凭证- 当前状态- 处理人- 处理结果
售后状态：- 待处理- 商家处理中- 平台处理中- 已同意- 已拒绝- 已退款- 已关闭
处理结果必须留痕，不允许删除。
12. 订单状态机
12.1 主状态
订单主状态包括：
1. 待支付2. 待商家接单3. 商家备餐中4. 待骑手取餐5. 配送中6. 已送达7. 已完成8. 已取消9. 退款中10. 已退款
12.2 状态流转规则
待支付：- 用户支付成功，进入待商家接单。- 用户取消，进入已取消。- 超时未支付，系统自动取消。
待商家接单：- 商家接单，进入商家备餐中。- 商家拒单，进入已取消并退款。- 用户取消，进入已取消并退款。- 商家超时未接单，系统提醒或自动取消。
商家备餐中：- 商家标记出餐，进入待骑手取餐。- 用户申请取消，需商家确认。
待骑手取餐：- 骑手取餐，进入配送中。- 骑手上报异常，进入异常处理但主状态可保持待取餐。
配送中：- 骑手确认送达，进入已送达。- 用户上报未收到，进入售后处理。
已送达：- 用户确认收餐或超时自动完成，进入已完成。- 用户申请售后，进入售后流程。
12.3 状态日志
每次状态变化必须记录：- 订单 ID- 原状态- 新状态- 操作人类型- 操作人 ID- 操作时间- 操作来源- 备注
13. 费用与结算规则
13.1 订单金额构成
订单应付金额包括：
菜品金额 + 规格加价 + 包装费 + 配送费 – 优惠金额 = 实付金额
13.2 包装费
包装费可按以下方式配置：
1. 按订单固定包装费。2. 按菜品独立包装费。3. 按数量叠加包装费。
V1.0 建议支持按菜品包装费，后台可配置。
13.3 配送费
配送费可按距离、门店、订单金额配置。V1.0 可采用简化规则：- 店铺固定配送费。- 满指定金额减免配送费，作为后续扩展。
13.4 退款金额
全额退款：
退还用户实付金额，优惠券是否返还由活动配置决定。
部分退款：
按菜品实付分摊金额退款。若优惠涉及满减，需要根据后台规则重新计算或人工处理。
13.5 商家结算
V1.0 可先做数据记录，不做完整财务结算系统。需要记录：- 订单原价- 优惠金额- 平台补贴- 商家承担优惠- 退款金额- 结算金额
14. 通知与消息
14.1 用户通知
用户通知场景包括：- 支付成功- 商家已接单- 商家已出餐- 骑手已取餐- 骑手即将送达- 订单已送达- 退款成功- 售后处理完成
通知形式包括 App 内消息、Push、短信，V1.0 可优先 App 内消息和 Push。
14.2 商家通知
商家通知场景包括：- 新订单- 用户取消订单- 用户申请退款- 骑手到店- 异常订单
新订单提醒必须明显，支持声音和弹窗。
14.3 骑手通知
骑手通知场景包括：- 新配送任务- 商家已出餐- 用户修改备注- 用户联系请求- 配送异常处理结果
15. 权限与安全
15.1 用户隐私
用户手机号、地址、订单记录属于敏感信息。系统需遵循最小可见原则。
要求：
1. 用户手机号默认脱敏展示。2. 骑手和商家仅在订单履约必要阶段查看用户联系信息。3. 后台查看完整手机号需具备权限。4. 地址信息不得用于非订单履约目的。5. 用户可删除地址。
15.2 后台权限
后台角色包括：- 超级管理员- 运营- 客服- 财务- 商家管理员
权限示例：- 客服可查看订单和处理售后，但不能修改优惠规则。- 运营可配置活动和处理异常订单。- 财务可查看结算数据，但不能修改订单状态。- 超级管理员可管理角色和权限。
15.3 操作日志
后台关键操作必须记录日志：- 修改订单状态- 发起退款- 修改商家信息- 修改优惠券- 禁用用户- 停用商家- 修改配送规则
16. 非功能需求
16.1 性能需求
1. 首页首屏加载时间不超过 2 秒。2. 店铺页菜品列表切换响应不超过 500ms。3. 提交订单接口平均响应不超过 1 秒。4. 支付成功回调后订单状态更新不超过 3 秒。5. 高峰期订单状态推送延迟不超过 5 秒。
16.2 可用性需求
1. 核心下单链路可用性目标 99.9%。2. 支付和订单状态不得因客户端退出而丢失。3. 商家端断网恢复后需重新同步未处理订单。4. 骑手端弱网情况下可缓存关键状态，恢复后补传。
16.3 兼容性需求
移动端需兼容：- iOS 最近 3 个主版本。- Android 主流系统版本。- 主流屏幕尺寸。
H5 或小程序扩展需适配微信环境。
16.4 可维护性需求
1. 订单状态机需要服务端统一管理。2. 费用计算需服务端统一计算，客户端只展示结果。3. 优惠规则应支持后台配置。4. 菜品、店铺、配送、售后规则应模块化，便于后续扩展。
17. 埋点需求
17.1 首页埋点- 首页曝光- 地址切换点击- 搜索框点击- 分类点击- 店铺卡片曝光- 店铺卡片点击- 推荐套餐点击
17.2 店铺页埋点- 店铺页曝光- 菜品曝光- 菜品加购- 规格弹窗打开- 规格确认- 购物车打开- 去结算点击
17.3 订单埋点- 订单确认页曝光- 优惠券点击- 提交订单点击- 支付发起- 支付成功- 支付失败- 取消订单点击- 再来一单点击
17.4 售后埋点- 售后入口点击- 售后类型选择- 售后提交- 售后成功- 售后失败
18. 风险与边界
18.1 业务风险
1. 午高峰订单集中，商家接单和出餐压力较大。2. 配送能力不足会直接影响用户体验。3. 优惠规则如果不清晰，容易引发价格争议。4. 商家菜品图片和实物差异可能导致差评。5. 售后审核如果过慢，会放大用户负面情绪。
18.2 产品边界
V1.0 重点是完成点餐履约闭环，不追求复杂营销玩法。所有新增功能都应优先判断是否提升下单效率、履约稳定性或售后处理效率。
18.3 技术风险
1. 支付回调和订单状态一致性要求高。2. 库存扣减和退款返还容易出现边界问题。3. 商家端、用户端、骑手端多端状态同步复杂。4. 高峰期推送延迟可能影响履约。
19. 验收标准
19.1 用户端验收
1. 用户可以手机号验证码登录。2. 用户可以新增、编辑、删除地址。3. 用户可以浏览首页店铺和分类。4. 用户可以进入店铺页查看菜品。5. 用户可以选择规格并加入购物车。6. 用户可以提交订单并完成支付。7. 用户可以查看订单状态。8. 用户可以取消符合条件的订单。9. 用户可以申请售后。10. 用户可以评价已完成订单。11. 用户可以通过历史订单再来一单。
19.2 商家端验收
1. 商家可以登录。2. 商家可以切换营业状态。3. 商家可以接单和拒单。4. 商家可以标记备餐完成。5. 商家可以管理菜品上下架和库存。6. 商家可以查看今日订单和基础经营数据。
19.3 骑手端验收
1. 骑手可以登录。2. 骑手可以查看配送任务。3. 骑手可以标记到店、取餐、送达。4. 骑手可以联系用户和商家。5. 骑手可以上报配送异常。
19.4 后台验收
1. 后台可以查看订单列表和订单详情。2. 后台可以管理用户、商家、骑手。3. 后台可以配置优惠券。4. 后台可以处理售后单。5. 后台可以查看数据看板。6. 后台关键操作有日志。
20. 版本规划
20.1 V1.0 MVP
目标：完成外卖点餐基础闭环。
范围：- 用户登录- 地址管理- 首页- 店铺页- 菜品规格- 购物车- 订单确认- 支付- 订单详情- 商家接单- 骑手配送- 售后- 基础后台
20.2 V1.1 体验优化
目标：提升复购和点餐效率。
范围：- 常点菜品- 收藏店铺- 智能默认地址- 更完善的评价标签- 商家出餐时长优化提示- 优惠券推荐
20.3 V1.2 运营增强
目标：提升活动和商家经营能力。
范围：- 店铺活动配置- 菜品排行榜- 用户分层- 商家经营分析- 异常订单自动预警- 售后原因分析
20.4 V2.0 扩展能力
目标：支持更复杂场景。
范围：- 多人点餐- 企业餐补- 发票管理- 会员体系- 拼单- 预约配送- 智能推荐- 多城市多商圈管理
21. 原型页面清单
用户端：
1. 启动页2. 登录页3. 定位授权页4. 地址列表页5. 新增地址页6. 首页7. 搜索页8. 搜索结果页9. 店铺页10. 菜品规格弹窗11. 购物车弹窗12. 订单确认页13. 支付结果页14. 订单列表页15. 订单详情页16. 取消订单页17. 售后申请页18. 评价页19. 我的页20. 优惠券页21. 客服中心页
商家端：
1. 登录页2. 工作台3. 订单列表4. 订单详情5. 菜品列表6. 菜品编辑7. 店铺设置8. 数据页
骑手端：
1. 登录页2. 任务列表3. 任务详情4. 异常上报
后台：
1. 登录页2. 数据看板3. 订单管理4. 订单详情5. 用户管理6. 商家管理7. 骑手管理8. 优惠券管理9. 售后管理10. 系统配置
22. 测试重点
22.1 主流程测试- 登录到下单支付全流程。- 支付成功后商家接单流程。- 商家出餐到骑手送达流程。- 用户评价流程。- 再来一单流程。
22.2 异常测试- 支付失败。- 支付成功但客户端断网。- 商家拒单。- 商家超时未接单。- 菜品库存不足。- 地址超出配送范围。- 骑手配送异常。- 用户申请退款。
22.3 金额测试- 起送价计算。- 包装费计算。- 配送费计算。- 满减券计算。- 配送券计算。- 部分退款金额计算。- 取消订单退款。
22.4 权限测试- 普通用户不能访问后台。- 商家只能查看自己店铺订单。- 骑手只能查看自己的配送任务。- 客服不能修改优惠规则。- 后台操作日志完整记录。
23. 待确认问题
1. V1.0 是否必须同时支持 App 和小程序，还是先做其中一个端。2. 配送由平台骑手承担，还是商家自配送，或两者都支持。3. 支付是否需要支持余额或企业餐补。4. 是否需要对接发票系统。5. 商家结算是否在 V1.0 内实现。6. 地图能力是否需要实时轨迹，还是只展示状态流转。7. 新人券和满减活动的补贴由平台承担还是商家承担。8. 售后自动退款的金额上限是多少。9. 是否需要支持预订单和预约配送。10. 是否需要企业团餐场景。
24. 总结
K姐食堂 V1.0 的核心不是做一个功能堆满的外卖平台，而是先把日常点餐最重要的链路跑稳：用户能快速选餐、清楚付款、实时看状态；商家能及时接单、准确出餐；骑手能顺利配送；平台能看见异常并处理售后。
这个版本应围绕三个关键词建设：效率、确定性、可追踪。
效率体现在首页、店铺页、购物车和复购链路。确定性体现在配送范围、库存、价格、订单状态和预计送达时间。可追踪体现在订单状态机、履约日志、售后记录和后台操作日志。

▲上下滑动查看全文

大家如果看过上面的提示词就知道，提示词超级长，专门用来测试 1M 上下文。

完成度挺高，每一个小窗口都是可以直接互动的，
覆盖面完整，一共做了 19 个展示界面。首页、店铺页、规格弹窗、确认订单、订单详情、售后、评价这些关键页面都有。后台页面不是摆设：数据看板、订单管理、售后管理都有。

后续只需要补交互、补状态、补真实素材和响应式就能变成一个完整的APP了。

case 2 3D 太阳系

第一个测试我们就来一个 3D 项目吧，以往基本每次模型测评都会有的项目。

提示词：做一个可交互的 3D 太阳系页面。要求：使用 Three.js。行星围绕太阳公转，轨道可见。点击行星后，侧边面板显示行星名称、半径、距离、介绍。支持播放/暂停、速度调节、视角拖拽、滚轮缩放。手机端改为上下布局，不能遮挡主体画面。出来的效果看起来真的很不错，该有的行星都有，交互也比较全。点击、拖拽、缩放、暂停、速度调节、重置视角都有。看得出模型的 Three.js 基础、页面整合能力、交互实现能力都很不错。

▲上下滑动查看全文

出来的效果看起来真的很不错，该有的行星都有，交互也比较全。点击、拖拽、缩放、暂停、速度调节、重置视角都有。效果展示视频：https://weixin.qq.com/sph/AobTs8a50看得出模型的 Three.js 基础、页面整合能力、交互实现能力都很不错。

case 3 射击游戏

接下来我们做一个射击游戏。

提示词：请输出完整单文件 HTML，用 Canvas 做一个类似《雷电》的竖版射击游戏。玩家战机可移动和射击，敌机分批出现并发射子弹；有碰撞检测、爆炸效果、分数、生命、关卡、暂停；每 30 秒出现 Boss；手机端有方向和射击按钮。

做完玩了十几分钟，是真的好玩，弥补了我小时候家长不让玩游戏机的遗憾。效果展示视频：https://weixin.qq.com/sph/AGFesU2uc战机、Boss、子弹、音效都有，还做了屏幕震动效果，玩法结构也完整，已经是一个完整的游戏了。GLM-5.2 显然理解了竖版射击游戏的基本骨架，能搭出主循环、实体系统、碰撞、移动端控制和视觉效果。

case 4 bug 修改

接下来测试一下 bug 修复能力，修复一个甘特图 HTML 文件，甘特图是典型工作场景，比普通表格更能看出前端状态设计能力。

提示词：下面是一段有 bug 的单文件 HTML，目标是做一个销售趋势图。请修复代码，并输出修复后的完整 HTML。不要只解释问题，必须给出能直接运行的完整代码。原始代码： Sales Chart body { margin: 0; background: #f5f5f5; } .wrap { width: 900px; margin: 40px auto; background: white; padding: 24px; } canvas { width: 100%; height: 300px; }

销售趋势 Q1 Q2

修复要求：修复所有导致图表无法正确切换的数据访问问题。切换 Q1 / Q2 时不能重复创建多个 Chart 实例导致内存泄漏。页面需要响应式，手机端宽度不能溢出。增加一个 KPI 区域，显示当前季度总销售额、总退款、净销售额。增加柱状图或折线图切换按钮。增加空状态和错误保护，如果传入不存在的季度，页面要显示友好提示。最后在代码注释里简短标出修复了哪些关键 bug。

▲上下滑动查看全文

修复前效果：

修复后效果：https://weixin.qq.com/sph/AS07Vq2uc

代码修得很完整。KPI、图表类型切换、响应式、空状态都补上了，说明模型理解了修 bug 的要求，还自动完善了使用体验。GLM 的前端 bug 修复能力不错：能读懂原始问题，能修核心 bug，也能主动补齐产品体验。

case 5 网页制作

我觉得审美也是一个模型的能力体现，我们让 GLM-5.2 生成一个官网页面试试。

提示词：请输出一个完整的单文件 HTML，包含 HTML、CSS、JavaScript，不依赖后端。可以使用 GSAP、Three.js、Lucide Icons 的 CDN，但不要使用 UI 模板库。主题：为一个名叫「LumaNote」的 AI 笔记产品制作官网首页。产品背景：LumaNote 面向研究生、产品经理、咨询顾问和内容创作者。核心功能包括：自动整理会议录音、把长文档变成结构化笔记、从多篇资料中提炼观点、生成可追溯引用、把笔记同步到 Notion 和 Obsidian。页面要求：首屏必须直接展示产品，不要做空泛大标题。需要有一个真实感的产品界面主视觉，可以用 HTML/CSS 做出笔记软件界面，也可以用 Canvas / Three.js 做互动展示。首屏包含产品名、清晰的一句话定位、主按钮和次按钮。页面至少包含 5 个完整区块：首屏、核心工作流、功能亮点、适用人群、价格方案、FAQ。核心工作流要展示「导入资料 → 自动整理 → 生成引用笔记 → 同步工具」这条链路，不能只列功能点。功能亮点至少 6 个，每个亮点要有图标、标题、简短说明。适用人群要针对 4 类用户分别写不同场景，文案不能重复。价格方案包含免费版、专业版、团队版，每档要有价格、适合谁、主要功能。FAQ 至少 5 个问题。页面需要有顶部导航，并支持点击平滑滚动到对应区块。移动端要适配，不能出现横向滚动、文字溢出、按钮遮挡。设计要求：整体风格要像成熟 SaaS 官网，克制、清爽、有高级感。不要使用大片紫蓝渐变、漂浮彩色光球、emoji 图标、模板化 bento 卡片。卡片圆角不要超过 8px。首屏主视觉不能只是装饰图，必须能看出产品是怎么处理笔记和引用的。使用统一字体层级、留白和颜色系统。交互要有细节，比如导航高亮、FAQ 展开、按钮 hover、工作流步骤切换或动效。所有文案用中文，语气像真实产品官网，不要写成 AI 味宣传稿。输出要求：只输出完整 HTML 代码。所有 CSS 和 JS 写在同一个文件里。不要解释设计思路。代码要能直接保存为 .html 并在浏览器打开运行。

▲上下滑动查看全文

GLM-5.2 生成的官网页面：

打开第一眼我还以为点进了哪个 AI 工具网站，AI 能做出审美这么牛的网页，太不真实了这种感觉。暖纸色背景、深色主按钮、细边框、低饱和棕色强调色配的非常舒适。已经从只会堆渐变卡片的坑跳出来了。

case 6 中文写作

大模型的中文写作水平真的是普通人很看重的一点了，比较很多上班族都需要 AI 给自己出点文案啥的。

提示词：请根据下面材料，写一篇 1200-1500 字的中文公众号文章。主题：AI 工具进公司一年后，真正有用的地方和没用的地方背景材料：一家 12 人内容团队从去年开始系统使用 AI 工具。团队主要做公众号文章、短视频脚本、行业资料整理和简单数据分析。使用一年后，周产出从 3 篇文章提高到 5 篇，资料整理时间减少约 40%，但初稿返工率没有明显下降。团队发现，AI 最适合做资料归纳、标题备选、表格清洗、采访提纲和初稿结构；最不适合直接写观点、判断行业趋势、替代编辑拍板。新人依赖 AI 后，文章更快成型，但观点经常变浅。资深编辑用 AI 更像用助理，可以省时间，但不会放弃人工判断。写作要求：

标题自拟，不要标题党。
开头直接进入具体场景，不要用“随着 AI 的发展”“在这个时代”这类套话。
文章要有个人判断，不能写成中立报告。
必须写清楚：AI 帮到了哪里、没帮到哪里、为什么同一个工具在新人和老手手里效果不同。
至少写 3 个具体工作场景。
不要使用“赋能、重塑、生态、闭环、底层逻辑、范式、降维打击”。
不要使用“不是……而是……”句式。
不要把每段都写成短句金句。
结尾给出一个具体建议，不要升华。
语气自然，像一个真的内容团队负责人写的复盘。

▲上下滑动查看全文

还挺快，两分钟不到就跑出来了！

文章整体读下来还是比较顺的，开头也能把读者拉住。新人和老手的对比很加分，有真实管理经验的味道，比单纯讲工具优缺点更有记忆点。如果满分 100 分，GLM-5.2 的写作能力我可以给到 85 分。

case 7 指令遵循

有很多模型经常把我们的指令搞错，看看GLM-5.2会不会有这样的问题。

提示词：请根据以下规则处理文本。规则优先级从高到低排列，冲突时只服从更高优先级规则。规则 A：最终答案只能输出 4 条项目符号。规则 B：每条项目符号必须少于 18 个中文字。规则 C：必须保留原文里的数字。规则 D：不要出现「提升」「优化」「打造」。原文：这套系统预计 30 天上线，目标是提升客服响应速度，优化工单分配流程，打造统一服务入口，并把人工处理比例降低到 40%。

很不错，4 条项目符号，每条少于 18 个中文字，保留数字，避开禁词都满足了

case 8 经典陷阱题

提示词：我要去洗车，我家离洗车店50米，我是开车去好，还是走路去好？

还好，没有落进陷阱里，还温馨提示可以先回来，等洗好再去取车。

case 9 PPT 制作

提示词：提示词：请根据下面材料制作一份 8 页以内的 PPTX，主题是「AI 工具在内容团队的落地方案」。要求：包含封面、现状问题、目标、流程设计、岗位分工、风险控制、试点计划、结尾页。使用稳重的商务风格，不要卡通插画。每页只保留必要文字，不能堆满段落。至少包含 1 张流程图和 1 张表格。生成可编辑 PPTX 文件，并导出预览图检查版式。材料如下：项目背景：公司是一家面向 B 端客户的 SaaS 服务商，主要客户来自制造、零售、教育和专业服务行业。内容团队负责公众号文章、客户案例、产品白皮书、短视频脚本、销售资料和活动物料。过去一年，内容需求明显增加。市场部希望把月度内容产出从现在的 18 篇提升到 30 篇，其中包括：公众号深度文章 8 篇。客户案例 4 篇。短视频脚本 12 条。行业资料整理 4 份。销售支持材料 2 份。当前团队已经尝试过使用 AI 工具，但主要靠个人习惯，没有统一流程。部分编辑用 AI 做资料整理和标题备选，部分编辑几乎不用。产出质量不稳定，审核标准也不统一。团队人数与角色：内容团队共 12 人：内容负责人 1 人，负责选题方向、最终审核、跨部门沟通。资深编辑 3 人，负责深度文章、客户案例、白皮书。初级编辑 3 人，负责资料整理、初稿、短内容改写。短视频编导 2 人，负责脚本、分镜、口播文案。设计师 1 人，负责封面图、信息图、PPT 视觉。运营 1 人，负责公众号发布、数据回收、社群分发。数据分析 1 人，负责内容效果分析和月报。当前主要问题：资料整理耗时长。一篇深度文章平均需要 6 到 8 小时做资料收集、摘录和核对。初稿质量波动大。初级编辑写出的初稿经常结构完整，但观点不够明确，返工率约 38%。标题和摘要依赖经验。不同编辑写法差异大，同一篇文章经常要反复改 4 到 6 版标题。客户案例生产慢。采访录音转文字后，需要人工整理重点，平均一篇案例从采访到成稿需要 7 天。内容复用不足。一篇白皮书很少被拆成短视频脚本、销售话术、社群短文，素材利用率不高。风险控制不稳定。AI 生成内容偶尔会出现事实错误、引用不明、夸大产品效果、语气过度营销等问题。现有数据：当前月均产出：18 篇内容。目标月均产出：30 篇内容。深度文章平均制作周期：3.5 天。客户案例平均制作周期：7 天。初稿返工率：38%。资料整理平均耗时：每篇 6 到 8 小时。标题平均修改轮次：4 到 6 轮。内容发布后 7 日内平均阅读完成率：42%。销售团队每月临时资料需求：约 15 次。落地目标：3 个月内把月度内容产出提升到 30 篇。把深度文章资料整理时间减少 40%。把客户案例制作周期从 7 天缩短到 4 天。把初稿返工率从 38% 降到 25% 以下。建立统一的 AI 使用规范和审核清单。每篇重点内容至少复用成 3 种形式，比如公众号文章、短视频脚本、销售话术。可使用工具清单：ChatGPT 或同类大模型：用于资料摘要、提纲、标题备选、初稿改写。Perplexity 或同类搜索工具：用于公开资料检索和来源追踪。飞书文档：用于协作、版本管理、审批流。Notion 或知识库工具：用于保存行业资料、客户案例、提示词模板。剪映或 CapCut：用于短视频脚本拆分、字幕初稿。Excel 或 Google Sheets：用于内容数据统计。Midjourney 或即梦：用于概念图、封面方向参考，但正式商用图必须由设计师确认。Grammarly 或中文校对工具：用于错别字、语病、标点检查。建议流程：选题阶段：内容负责人确定主题、目标读者、核心观点。资料阶段：初级编辑用 AI 整理资料摘要，必须保留来源链接。提纲阶段：资深编辑确定文章结构和主观点。初稿阶段：AI 辅助生成段落草稿，作者负责判断和改写。审核阶段：使用事实核查清单、品牌语气清单、敏感表述清单。复用阶段：把长文拆成短视频脚本、社群短文、销售话术。复盘阶段：运营和数据分析每周回收阅读、转化、完读率数据。岗位分工建议：内容负责人：确定选题优先级、审核核心观点、审批发布。资深编辑：负责文章判断、提纲、最终改稿。初级编辑：负责资料整理、初稿生成、来源标注。短视频编导：把长文拆成脚本、口播稿、分镜。设计师：负责视觉风格、封面图、信息图。运营：负责发布排期、分发渠道、评论反馈整理。数据分析：负责效果追踪、月度报告、选题建议。风险控制要求：所有事实、数据、引用必须人工复核。AI 生成内容不能直接发布。涉及客户名称、合同信息、销售数据时，不得输入公开 AI 工具。产品能力描述必须由产品或售前确认。医疗、金融、法律等敏感行业内容需要额外审核。所有 AI 生成图片必须检查版权和商用风险。文章最终观点必须由作者本人确认，不能只采用 AI 结论。预算：试点期预算为 9 万元，周期 3 个月。预算拆分：AI 工具账号：3 万元。内部培训和提示词模板建设：2 万元。知识库整理和流程配置：1.5 万元。设计和视频辅助工具：1.5 万元。预留费用：1 万元。时间安排：第 1 周：确认试点范围，选定工具，建立账号权限。第 2 周：整理常用提示词模板和审核清单。第 3 到 4 周：选择公众号文章和客户案例两个内容类型做小范围试点。第 5 到 8 周：扩大到短视频脚本和销售资料，开始每周复盘。第 9 到 10 周：根据数据调整流程，补充风险控制规则。第 11 到 12 周：形成正式 SOP，输出试点报告和下一阶段预算建议。试点范围：第一阶段只覆盖 4 类内容：公众号深度文章。客户案例。短视频脚本。销售支持材料。暂不纳入：高管署名文章。重大品牌发布稿。涉及未公开客户数据的内容。法务风险较高的行业报告。衡量指标：月度内容产出数量。单篇内容平均制作周期。资料整理耗时。初稿返工率。标题修改轮次。发布后 7 日阅读完成率。销售团队对资料可用性的评分。AI 内容审核发现的问题数量。预期结果：3 个月试点后，内容团队应该形成一套可复用的 AI 工作流程。AI 主要承担资料整理、结构草稿、标题备选、内容复用和数据初筛工作。核心观点、事实核查、客户表达和最终发布判断仍由人工负责。

▲上下滑动查看全文

任务需求方面是达标的，能看出来对项目内容理解很透，审美也还算合格，已经算可以使用了，人工稍微再精细调整一下就能直接拿去汇报。

一些分享

GLM-5.2 测下来之后，感觉前面几个榜单或许还真没啥水分。任务的结果我觉得都很牛，国内模型的顶尖水平了，不仅能跑，能用，还用着舒服。以前上班的时候，资料整理、代码初版、页面搭建、PPT 结构、测试样例，都要一点点磨，现在可以交给模型先跑一版，人把精力放回判断和取舍上。我对 GLM-5.2 的评价是：上限高，完成度也稳，已经值得放进日常工作流里认真试用。至于能不能长期留下来，还要看后面几周高频使用时，模型在细节、稳定性和成本上的表现。以后接 API 的时候，或许根本分不清接的是 GLM-5.2 还是 Claude oups 了。

作者：yuye&K姐投稿邮箱：tougao@kseek.ai