提示词结构化优化专家

优化说明

• 重构任务为“主题聚类+频次估算+引述选取+运营建议+高层摘要”的标准化流程，统一术语与编号，明确双重输出（报告JSON与目录式大纲）
• 补充字段与变量设计、质量校验与可追溯元数据，提升复用性与执行一致性
• 采用层级标签（L1/L2）与覆盖占比估算方法，确保在小样本场景下的信息密度与稳定性

优化版本

• 任务角色与目标

  • 角色：数据分析与商业咨询领域模型
  • 目标：对开放题反馈进行主题聚类（L1/L2）、估算主题覆盖占比、挑选代表性引述、输出运营改进建议与高层摘要；生成两份输出：报告JSON与可复制目录式大纲；隐去个人信息；提供术语表（中英对照）；确保复用与追溯

• 输入规范

  • FEEDBACK_LIST：开放题反馈数组，每条包含
    • id（字符串，保留原编号，如“A1”）
    • text（字符串，原文）
    • timestamp（可选，ISO8601）
    • channel（可选，来源渠道）
  • TAXONOMY（可选）：主题标签体系与映射规则；如未提供，使用默认体系
  • PARAMETERS（可选）：处理参数
    • language="zh"
    • top_k_quotes_per_theme=1
    • max_recommendations=6
    • output_versions={json:true, outline:true}
    • pii_masking=true

• 字段与变量定义

  • 主题标签体系（默认）
    • L1 客服服务
      • L2 响应速度、态度耐心、问题解决能力
    • L1 物流与发货
      • L2 发货时效、配送速度
    • L1 包装与环保
      • L2 环保包装认可、包装质量
    • L1 价格与性价比
      • L2 价格偏高、性价比评价
    • L1 产品功能与易用性
      • L2 基本功能满足、上手难度/学习曲线
    • L1 发票与流程
      • L2 发票申请流程复杂、流程清晰度
  • 频次指标
    • item_count：反馈条数
    • theme_item_coverage：提及该主题的反馈条数/N（覆盖占比）
    • subtheme_item_coverage：提及该子主题的反馈条数/N
    • avg_labels_per_item：平均每条反馈命中标签数量
  • 元数据
    • project_id、dataset_id、process_id、taxonomy_version、model_version、timestamp

• 数据处理流程

  1. 预处理
     • 去重、去噪；检测并掩码PII（邮箱/手机号/地址等）
     • 保留编号id（如A1…A5）
  2. 主题映射
     • 基于规则与语义匹配，将每条反馈映射到一个或多个L2；L2归属其L1
     • 若未命中默认标签，生成“未分类/需复审”
  3. 频次估算
     • 以反馈条数为分母（N），计算“覆盖占比”：每个主题被多少条反馈提及/ N
     • 支持多标签：一条反馈可命中多个主题，各主题覆盖计数均+1
  4. 代表性引述
     • 每主题选取top_k_quotes_per_theme条原文引述（保留id），避免可识别PII
  5. 运营建议与高层摘要
     • 每主题输出可执行建议（含优先级：高/中/低；影响/投入）
     • 汇总生成高层摘要：关键主题、主风险与机会、优先行动
  6. 输出构建
     • 报告JSON（含schema、数据、术语表、方法说明、追溯映射）
     • 目录式大纲（可复制）
  7. 质量校验
     • 一致性、覆盖率、术语统一、编号完整、PII屏蔽与可追溯性

• 输出规范

  • 输出一：报告JSON（字段结构）
    • meta：project_id、dataset_id、process_id、taxonomy_version、model_version、timestamp、language、item_count
    • method：frequency_estimation="item_coverage"，multi_label=true，rules_version
    • taxonomy：L1/L2列表与定义
    • clusters：[ {l1, l1_count, l1_coverage_pct, l2_children:[{l2, l2_count, l2_coverage_pct}]} ]
    • quotes：[{id, l1, l2, quote}]
    • recommendations：[{id, l1, l2, recommendation, priority, impact, effort, owner, timeline}]
    • exec_summary：文本
    • glossary：中英对照术语
    • trace_map：[{id, labels:[{l1,l2}]}]
    • quality_checks：[ {check, status, notes} ]
    • pii_masking：enabled/disabled
  • 输出二：可复制目录式大纲
    • I. 项目与方法
    • II. 主题聚类（L1/L2与覆盖占比）
    • III. 代表性引述
    • IV. 运营改进建议（优先级）
    • V. 高层摘要
    • VI. 术语表（中英）
    • VII. 质量校验与追溯

• 频次估算方法

  • 定义：覆盖占比=提及该主题的反馈条数 / N（N为反馈总数）
  • 多标签：一条反馈可同时计入多个主题覆盖；避免在同一条内重复计数同一子主题
  • 小样本建议：报告覆盖占比至整数或5%粒度，标注样本量N

• 重构提示词（供模型执行）

  • 角色：你是数据分析与商业咨询领域专家。按输入规范处理FEEDBACK_LIST，使用默认或提供的TAXONOMY，完成主题聚类（L1/L2）、覆盖占比估算、代表性引述选取、运营建议与高层摘要，并生成两份输出：报告JSON与可复制目录式大纲。严格保留反馈编号，统一术语，隐藏个人信息，确保复用与追溯。按输出规范返回结果。
  • 任务要求：
    1. 主题映射：为每条反馈打L2标签，并归入L1；支持多标签
    2. 频次估算：计算L1/L2覆盖占比（分母=N）
    3. 引述：各主题挑选1条代表性引述（保留id；去PII）
    4. 建议：给出可执行运营建议（含priority/impact/effort/owner/timeline）
    5. 摘要：输出高层摘要（关键词、优先级结论）
    6. 输出：按“报告JSON”与“目录式大纲”双格式，附术语表与质量校验
  • 约束：
    • 编号不丢失；术语统一；不引入个人信息；方法透明可追溯
    • 若文本含歧义，标注“需复审”并不强行归类

• 示例（基于提供的A1–A5）

  • 报告JSON示例 { "meta": { "project_id": "PRJ-OPENFEEDBACK-001", "dataset_id": "DS-2024Q4-EXCERPT", "process_id": "PROC-0001", "taxonomy_version": "TX-1.0", "model_version": "ANALYTICS-PRO", "timestamp": "2025-12-02T00:00:00Z", "language": "zh", "item_count": 5 }, "method": { "frequency_estimation": "item_coverage", "multi_label": true, "rules_version": "R-1.0" }, "taxonomy": { "L1": [ {"name": "客服服务", "L2": ["响应速度", "态度耐心", "问题解决能力"]}, {"name": "物流与发货", "L2": ["发货时效", "配送速度"]}, {"name": "包装与环保", "L2": ["环保包装认可", "包装质量"]}, {"name": "价格与性价比", "L2": ["价格偏高", "性价比评价"]}, {"name": "产品功能与易用性", "L2": ["基本功能满足", "上手难度/学习曲线"]}, {"name": "发票与流程", "L2": ["发票申请流程复杂", "流程清晰度"]} ] }, "clusters": [ { "l1": "物流与发货", "l1_count": 2, "l1_coverage_pct": "40%", "l2_children": [ {"l2": "发货时效", "l2_count": 1, "l2_coverage_pct": "20%"}, {"l2": "配送速度", "l2_count": 1, "l2_coverage_pct": "20%"} ] }, { "l1": "客服服务", "l1_count": 2, "l1_coverage_pct": "40%", "l2_children": [ {"l2": "响应速度", "l2_count": 1, "l2_coverage_pct": "20%"}, {"l2": "态度耐心", "l2_count": 1, "l2_coverage_pct": "20%"}, {"l2": "问题解决能力", "l2_count": 1, "l2_coverage_pct": "20%"} ] }, { "l1": "包装与环保", "l1_count": 1, "l1_coverage_pct": "20%", "l2_children": [ {"l2": "环保包装认可", "l2_count": 1, "l2_coverage_pct": "20%"} ] }, { "l1": "价格与性价比", "l1_count": 1, "l1_coverage_pct": "20%", "l2_children": [ {"l2": "价格偏高", "l2_count": 1, "l2_coverage_pct": "20%"} ] }, { "l1": "产品功能与易用性", "l1_count": 1, "l1_coverage_pct": "20%", "l2_children": [ {"l2": "基本功能满足", "l2_count": 1, "l2_coverage_pct": "20%"}, {"l2": "上手难度/学习曲线", "l2_count": 1, "l2_coverage_pct": "20%"} ] }, { "l1": "发票与流程", "l1_count": 1, "l1_coverage_pct": "20%", "l2_children": [ {"l2": "发票申请流程复杂", "l2_count": 1, "l2_coverage_pct": "20%"} ] } ], "quotes": [ {"id": "A1", "l1": "物流与发货", "l2": "发货时效", "quote": "下单后两天才发货"}, {"id": "A1", "l1": "客服服务", "l2": "响应速度", "quote": "问客服回得很慢"}, {"id": "A2", "l1": "包装与环保", "l2": "环保包装认可", "quote": "包装环保，我喜欢"}, {"id": "A2", "l1": "价格与性价比", "l2": "价格偏高", "quote": "但价格略高"}, {"id": "A3", "l1": "产品功能与易用性", "l2": "基本功能满足", "quote": "功能够用"}, {"id": "A3", "l1": "产品功能与易用性", "l2": "上手难度/学习曲线", "quote": "就是新手上手不快"}, {"id": "A4", "l1": "客服服务", "l2": "态度耐心", "quote": "客服挺耐心的"}, {"id": "A4", "l1": "客服服务", "l2": "问题解决能力", "quote": "问题最后解决了"}, {"id": "A5", "l1": "物流与发货", "l2": "配送速度", "quote": "物流快"}, {"id": "A5", "l1": "发票与流程", "l2": "发票申请流程复杂", "quote": "但发票申请流程绕"} ], "recommendations": [ { "id": "R1", "l1": "物流与发货", "l2": "发货时效", "recommendation": "设定并公开发货SLA（<24小时），对超时订单自动预警与补偿机制", "priority": "高", "impact": "高", "effort": "中", "owner": "运营/供应链", "timeline": "2-4周" }, { "id": "R2", "l1": "客服服务", "l2": "响应速度", "recommendation": "优化客服排班与工单优先级，引入智能分流与响应时限考核", "priority": "高", "impact": "中高", "effort": "中", "owner": "客服中心", "timeline": "2-3周" }, { "id": "R3", "l1": "客服服务", "l2": "问题解决能力", "recommendation": "强化知识库与复盘机制，保持耐心优势并提升一次解决率", "priority": "中", "impact": "中", "effort": "低中", "owner": "客服中心", "timeline": "2周" }, { "id": "R4", "l1": "价格与性价比", "l2": "价格偏高", "recommendation": "评估环保包装溢价策略，推出限时优惠或会员折扣以提升感知价值", "priority": "中", "impact": "中", "effort": "低", "owner": "市场/定价", "timeline": "1-2周" }, { "id": "R5", "l1": "产品功能与易用性", "l2": "上手难度/学习曲线", "recommendation": "提供新手引导与快捷教程，减少初次上手时间", "priority": "中", "impact": "中", "effort": "低中", "owner": "产品/培训", "timeline": "2-3周" }, { "id": "R6", "l1": "发票与流程", "l2": "发票申请流程复杂", "recommendation": "简化发票申请路径，整合入口与状态可视化，提供标准化指引", "priority": "中", "impact": "中", "effort": "中", "owner": "财务/产品", "timeline": "3-4周" } ], "exec_summary": "小样本（N=5）显示两大关注点：发货时效与客服响应速度（均40%覆盖）。客户认可环保包装但对价格敏感；新手上手存在阻滞；发票流程需简化。优先建议集中于发货SLA与客服响应优化，其次推进发票流程与新手引导，配合价格/价值沟通策略。", "glossary": [ {"term_zh": "覆盖占比", "term_en": "coverage percentage"}, {"term_zh": "主题聚类", "term_en": "topic clustering"}, {"term_zh": "层级标签（L1/L2）", "term_en": "hierarchical labels (L1/L2)"}, {"term_zh": "代表性引述", "term_en": "representative quotes"}, {"term_zh": "可追溯性", "term_en": "traceability"}, {"term_zh": "学习曲线", "term_en": "learning curve"}, {"term_zh": "发货时效", "term_en": "dispatch timeliness"}, {"term_zh": "配送速度", "term_en": "delivery speed"}, {"term_zh": "响应速度", "term_en": "response time"}, {"term_zh": "问题解决能力", "term_en": "issue resolution capability"} ], "trace_map": [ {"id": "A1", "labels": [{"l1": "物流与发货", "l2": "发货时效"}, {"l1": "客服服务", "l2": "响应速度"}]}, {"id": "A2", "labels": [{"l1": "包装与环保", "l2": "环保包装认可"}, {"l1": "价格与性价比", "l2": "价格偏高"}]}, {"id": "A3", "labels": [{"l1": "产品功能与易用性", "l2": "基本功能满足"}, {"l1": "产品功能与易用性", "l2": "上手难度/学习曲线"}]}, {"id": "A4", "labels": [{"l1": "客服服务", "l2": "态度耐心"}, {"l1": "客服服务", "l2": "问题解决能力"}]}, {"id": "A5", "labels": [{"l1": "物流与发货", "l2": "配送速度"}, {"l1": "发票与流程", "l2": "发票申请流程复杂"}]} ], "quality_checks": [ {"check": "编号完整", "status": "pass", "notes": "A1-A5保留"}, {"check": "术语统一", "status": "pass", "notes": "使用默认taxonomy"}, {"check": "覆盖率计算", "status": "pass", "notes": "分母N=5"}, {"check": "PII屏蔽", "status": "pass", "notes": "无可识别PII"}, {"check": "可追溯性", "status": "pass", "notes": "trace_map已提供"} ], "pii_masking": "enabled" }
  • 目录式大纲示例 I. 项目与方法
    • 项目：开放题反馈分析（节选，N=5）
    • 方法：层级标签聚类，覆盖占比=item_coverage，多标签支持 II. 主题聚类（L1/L2与覆盖占比）
    • 物流与发货（40%）：发货时效（20%）、配送速度（20%）
    • 客服服务（40%）：响应速度（20%）、态度耐心（20%）、问题解决能力（20%）
    • 包装与环保（20%）：环保包装认可（20%）
    • 价格与性价比（20%）：价格偏高（20%）
    • 产品功能与易用性（20%）：基本功能满足（20%）、上手难度/学习曲线（20%）
    • 发票与流程（20%）：发票申请流程复杂（20%） III. 代表性引述
    • A1：下单后两天才发货；问客服回得很慢
    • A2：包装环保，我喜欢；但价格略高
    • A3：功能够用；就是新手上手不快
    • A4：客服挺耐心的；问题最后解决了
    • A5：物流快；但发票申请流程绕 IV. 运营改进建议（优先级）
    • 发货SLA与预警（高）
    • 客服分流与响应考核（高）
    • 发票流程简化（中）
    • 新手引导优化（中）
    • 价格与价值沟通（中） V. 高层摘要
    • 核心关注：发货与客服响应；正向：环保包装；敏感点：价格；阻滞：新手上手；流程：发票申请 VI. 术语表（中英）
    • 覆盖占比 coverage percentage；主题聚类 topic clustering；层级标签 hierarchical labels；代表性引述 representative quotes；学习曲线 learning curve VII. 质量校验与追溯
    • 编号保留、术语统一、覆盖率计算、PII屏蔽、trace_map

优化要点

• 明确双输出（JSON与目录式大纲），提供统一schema与大纲模板
• 采用层级标签体系（L1/L2）与item_coverage频次估算，适配小样本
• 设计变量与元数据，保证复用与追溯（process_id、taxonomy_version等）
• 标准化代表性引述与运营建议结构，绑定主题标签与优先级
• 内置质量校验清单，确保编号、术语、覆盖率与隐私合规

使用建议

• 直接以“重构提示词”作为主指令，在调用模型时注入FEEDBACK_LIST与可选TAXONOMY
• 若扩展至大样本，保持方法不变；仅调整top_k与建议上限，并记录版本号
• 在多批次执行时，复用meta字段与process_id以串联追溯链，确保术语与标签版本一致

• 优化说明

  • 明确角色与交付物，统一术语并变量化技术栈
  • 重构为“方案版+执行版”双轨输出，覆盖WBS、接口草图、代码框架、测试与验收、风控与回滚、灰度与监控、Swagger
  • 引入最小可行范围优先策略与可选提醒功能的复杂度判定
  • 统一配置与权限模型，避免对现有系统造成影响
  • 适配代码生成模型，规范输出结构、变量字典与代码块格式

• 优化版本

  • 角色设定

    • 你是资深架构师兼交付工程师，擅长产品管理、流程自动化与可落地的工程实现。你的目标是在最短时间交付“周报自动化工具”的MVP，并提供可演进的架构与实现。

  • 目标与范围

    • 目标：每周五18:00从共享表格抓取项目进展，生成摘要并发送到团队群；出现异常项时@负责人。提供分级权限与审计日志；不影响现有系统；支持灰度发布、简单监控、Swagger。
    • 可选：提醒功能。如果复杂度低则实现，否则暂缓并给出后续计划。
    • 最小可行产品(MVP)范围：
      • 单一数据源表格读取
      • 单一团队群发送
      • 简单异常规则与@负责人映射
      • 基本RBAC（Admin/Operator/Viewer）
      • 基本审计日志、健康检查、指标
      • OpenAPI(Swagger)文档
      • 灰度=按开关与百分比/名单分流
    • 非目标（MVP之外）：跨多表合并、复杂规则引擎、统一告警平台、跨租户SaaS、多云联动。

  • 术语统一

    • 周报自动化工具：本服务
    • 共享表格：外部表格数据源
    • 团队群：目标消息渠道
    • 异常项：不满足既定规则的项目进展记录（如延期、阻塞、缺失关键字段）
    • 提醒功能：对未读或未处理异常的重复提醒
    • 灰度发布：对少量用户或渠道先行启用，逐步扩大范围
    • RBAC：基于角色的访问控制
    • 审计日志：对配置变更与手工触发操作的记录

  • 变量字典（请在执行前填充）

    • {lang}: 编程语言与框架（示例：Node.js/Express 或 Python/FastAPI 或 Go/Gin）
    • {db}: 数据库（示例：PostgreSQL/MySQL/SQLite）
    • {cloud}: 部署/云环境（示例：Docker+Kubernetes on {cloud}）
    • {sheet_provider}: 表格提供方（GoogleSheets/ExcelOnline/Airtable/...）
    • {messaging_platform}: 消息平台（企业微信/钉钉/Slack/Teams/...）
    • {timezone}: 时区（示例：Asia/Shanghai）
    • {cron}: 调度表达式（示例：0 18 * * FRI）
    • {service_name}: 服务名（示例：weekly-report-bot）
    • {env}: 环境（dev/staging/prod）
    • {namespace}: 部署命名空间
    • {alert_channel}: 监控/告警输出渠道（可与{messaging_platform}一致）
    • {owner_mapping_store}: 负责人映射存储（配置表/DB表/JSON文件）
    • {auth_provider}: 认证方式（JWT/OIDC/Basic）
    • {feature_flag_provider}: 开关方案（环境变量/DB/文件/FFaaS）
    • {log_level}: 日志等级（info/warn/error）
    • {metrics_stack}: 指标方案（/metrics + Prometheus 文本格式）
    • {sheet_columns}: 关键列名定义（如：项目名、负责人、进度、风险、更新时间）

  • 输入/输出与约束

    • 输入：表格数据、配置（调度、渠道、异常规则、负责人映射、灰度策略）
    • 输出：群消息摘要、异常@提醒、API响应、日志与指标
    • 约束：只读访问外部系统；通过新服务对外输出，不侵入现有系统；敏感信息使用占位符；统一术语与接口风格；优先MVP

  • 功能要求与规则

    • 数据抓取：按{cron}在{timezone}执行；支持即时手动触发
    • 摘要生成：按项目分组输出进展、异常汇总；模板化
    • 异常识别：示例规则（任填/可配置）
      • 进度较计划落后X天
      • 风险/阻塞字段为true
      • 未更新超过Y天
    • @负责人：通过{owner_mapping_store}映射到{messaging_platform}的可@标识
    • 权限分级（RBAC）
      • Admin：读写配置、手动执行、查看日志
      • Operator：手动执行、查看日志
      • Viewer：只读查看
    • 审计日志：记录谁在何时对何配置做了什么变更/执行
    • 提醒功能（可选）：若{messaging_platform}原生支持轻量级计划消息或重复提醒，且无需额外队列/持久化，即实现；否则输出“延后方案+验收口径”，MVP不实现
    • 灰度发布：基于开关或名单对群、用户或百分比分流；默认关闭，先在staging验证
    • 监控：/health, /metrics, 关键业务指标（任务触发次数、成功/失败、发送耗时）
    • 文档：OpenAPI(Swagger) 3.0，覆盖所有接口
    • 安全：令牌/OIDC；最小权限；敏感配置经密钥管理

  • 交付物结构（你必须严格按以下结构输出）

    • 方案版
      1. WBS（含里程碑与最小可行范围标注）
      2. 架构与流程图（文字描述/ASCII框架）与数据模型
      3. 接口列表草图（Endpoint、Method、Purpose、核心字段）
      4. 配置与变量清单（含默认值与覆盖策略）
      5. 验收标准（Gherkin Given-When-Then）
      6. 风控与回滚方案（含失败场景与演练步骤）
      7. 灰度发布与简单监控方案
      8. 术语表与一致性约束
      9. 提醒功能复杂度评估与决策依据
      10. 重构提示词与示例（用于后续增量需求）
      11. 评审清单（架构、代码、文档、运维、合规）
    • 执行版
      1. 代码框架与目录结构（{lang}）
      2. 关键模块样例代码（调度、数据抓取、摘要生成、@负责人、RBAC、审计日志、灰度开关、监控、错误处理）
      3. 数据库与迁移脚本样例（{db}）
      4. OpenAPI 3.0 YAML（Swagger）草案
      5. 配置样例（.env/.yaml），含{feature_flag_provider}
      6. 测试计划与示例（单测/集成/契约），含Gherkin特性文件样例
      7. 本地与容器化运行脚本（含{cloud}部署占位）
      8. 只读集成示例（对现有系统零侵入）
      9. 灰度验证脚本与回滚脚本样例
      10. 注意事项（性能、限流、重试、幂等、时区与字符集）
      11. 术语与常量统一定义位置

  • 接口列表草图（示例需在方案版给出精炼清单，在执行版补充OpenAPI细节）

    • GET /health
    • GET /metrics
    • GET /api/v1/config
    • PUT /api/v1/config
    • POST /api/v1/jobs/run
    • GET /api/v1/summaries/preview
    • GET /api/v1/logs
    • GET /api/v1/swagger（或 /docs 重定向）
    • 认证：{auth_provider}；所有写操作需Admin，执行需Operator+

  • 验收标准（示例片段，完整版本请在方案版展开）

    • Feature: 周报自动化按时抓取并发送
      • Given 已配置{cron}与{timezone}且表格可访问
      • When 到达周五18:00或手动触发
      • Then 生成摘要并发送到{messaging_platform}的团队群
    • Feature: 异常项@负责人
      • Given 表格中项目A标记为延迟
      • When 生成摘要
      • Then 消息中包含对项目A负责人的@提及
    • Feature: RBAC与审计
      • Given 用户为Viewer
      • When 调用PUT /api/v1/config
      • Then 返回403且无配置变更审计记录
    • Feature: 灰度
      • Given 灰度开关开启且名单仅包含团队群B
      • When 任务执行
      • Then 仅对团队群B发送消息

  • 风控与回滚（要点）

    • 风险：调度失败、API配额超限、消息发送失败、配置误改、异常规则误报/漏报
    • 缓解：重试与退避、限流、幂等键、预发布验证、只读模式、变更双人复核
    • 回滚：特性开关关闭→回滚容器版本→回滚配置→数据恢复（如变更日志反向迁移）

  • 提醒功能决策准则

    • 满足以下条件即实现：消息平台支持原生计划/延时消息API，且无需引入消息队列/定时器持久化；否则暂缓并输出后续方案（引入持久化任务表与重试机制）

  • 适配代码生成模型的输出规范

    • 严格按“方案版/执行版”两大段输出
    • 代码块使用三引号，并标注语言：{lang}；OpenAPI使用yaml
    • 使用变量占位，禁止写入真实公司/个人/密钥信息
    • 优先给出可运行的最小示例，其余以TODO标注

  • 开始执行

    • 按上述交付物结构，完整输出“方案版”与“执行版”。在生成执行版代码示例时，统一使用{lang}/{db}/{cloud}与其生态的最通用做法；若存在分歧，优先选择可最快上线的方案并在注释中说明权衡。

• 优化要点

  • 引入明确角色与目标，统一术语与变量字典，便于复用与落地
  • 按MVP优先原则界定范围，降低首次交付复杂度
  • 将交付拆分为“方案版+执行版”，确保从规划到代码的一致性
  • 设计RBAC与审计、灰度与监控、Swagger与测试的闭环
  • 给出可选提醒功能的复杂度判定，避免过早优化
  • 提供严格的接口草图与Gherkin验收标准，提高可测试性与对齐度
  • 适配代码生成模型的格式规范，确保生成内容可直接使用

• 使用建议

  • 在使用前先填充变量字典的关键项：{lang}、{db}、{cloud}、{sheet_provider}、{messaging_platform}、{timezone}、{cron}
  • 若时间紧张，先仅启用staging环境与手动触发路径，确认消息模板正确后再启用定时
  • 采用最常用栈（如 Node.js/Express + PostgreSQL + Docker）可加速生成与上线
  • 先按MVP发布，提醒功能按决策准则评估后再纳入下一迭代