✨文章摘要（AI生成）

本文以一个 15,400 tokens 的登录 Bug 修复场景为切入点，深入拆解了三款主流 CLI Agent（Codex CLI、Claude Code、OpenCode）的上下文压缩策略。Codex CLI 采用"工作交接单"式的单层摘要替换；Claude Code 设计了三层递进机制——工具结果修剪、Prompt Cache 友好策略和 9 部分结构化 LLM 总结；OpenCode 则以非物理删除的时间戳标记隐藏配合 5 标题 LLM 摘要实现"阶梯治理"。文章揭示了一个核心洞察：最好的上下文管理不是无限扩大记忆容量，而是学会精密地遗忘。

在使用 AI Agent 深度参与编程任务时，你一定遇到过这种窘境：起初 AI 反应敏捷，指哪打哪；但随着对话轮次增加，它似乎开始变得越来越笨。

上下文快用完的时候，AI会着急完成导致效果不佳，社区中称作 Context Anxiety (上下文焦虑)，和我们人一样，着急就容易出错。为了维持对话，Agent 必须丢掉一部分记忆（压缩 - Compact）。但怎么丢、丢掉谁、丢掉后怎么补救，成了衡量一个 Agent 运行时（Runtime）是否成熟的分水岭之一。

今天笔者就带大家拆解三款主流 CLI Agent——Codex CLI、Claude Code 和 OpenCode。看看它们在面对同一个登录 Bug 时，是如何施展各自的"压缩大法"的。

注：本文分析基于 Codex CLI 与 OpenCode 的开源仓库逻辑，以及社区逆向研究与泄露源码对 Claude Code 运行时的验证。

场景回放：一场价值 15,400 Tokens 的登录修复 ​

假设你正在修复一个登录接口报 401 Unauthorized 的 Bug。你召唤了 AI Agent，并经历了一番激烈的排查。

下面是这段对话的完整记录：

看起来不过 26 条消息，但已经吃掉了约 15,400 tokens。其中加粗的五条工具结果（#5, #8, #13, #21, #26）合计约 12,500 tokens，占了 81%。这些数据在排查时至关重要，但 Bug 修好后，它们就变成了上下文里沉重的负担。如果不处理，下一轮对话可能因为窗口溢出而丢掉系统提示词或用户的核心需求。

Codex CLI：写一份干练的"工作交接单" ​

OpenAI 的 Codex CLI（源码，Rust 实现）走的是一种非常符合人类直觉的路线：总结与替换。

它的核心思想可以用一句话概括：把之前的全部对话交给 LLM 写一份"工作交接摘要"，然后用这份摘要替换掉原始历史。

双路径设计 ​

Codex 提供了两条压缩路径：

1. 本地路径（compact.rs）：在客户端调用 LLM 生成摘要，适用于所有模型提供商。
2. 远程路径（compact_remote.rs）：直接调用 OpenAI 的内部 API 端点 responses/compact，让服务器完成压缩。仅限 OpenAI 自家模型。

注意，这里的"本地"和"远程"指的不是是否需要调用 LLM——两条路径都需要 LLM 参与，区别在于**"生成摘要"这个核心步骤跑在哪里**。本地路径下，客户端自己构造摘要 Prompt（从内置模板 templates/compact/prompt.md 加载）、通过 ModelClientSession 流式调用 LLM API、再处理返回结果，整个编排流程都在你的机器上完成，所以它能对接任意模型提供商。远程路径下，客户端把准备好的对话历史和工具定义发给 OpenAI 的 compact_conversation_history 端点，由服务器完成摘要生成——但客户端并非"甩手掌柜"，它在调用前后仍然承担了大量工作：调用前要修剪过长的函数调用历史、构建包含工具规范和系统指令的完整 Prompt 对象；调用后要过滤返回结果（比如丢弃过时的 developer 角色消息、只保留真实的用户和助手内容）、恢复用于 /undo 功能的 ghost snapshots、以及重新计算 token 用量。

简单说，远程路径只是把**"压缩"这一步**外包给了 OpenAI 服务器，前处理和后处理仍由客户端完成。这种设计的优势在于：OpenAI 服务端很可能对这个端点做了专门优化（比如使用更经济的模型或内部缓存），这些是客户端走通用 API 做不到的。这体现了 OpenAI 对自家基础设施的垂直整合。

压缩的具体流程 ​

当走本地路径时，Codex 会先提取最近的用户消息（硬上限约 20,000 tokens），然后发送一段简短的 Summarization Prompt 给 LLM。这段 Prompt 只有 4 个核心要点：

你正在执行一次"上下文检查点压缩"。请为另一个将接续任务的 LLM 生成一份交接摘要，包含：当前进展和关键决策、重要的约束和用户偏好、剩余待办事项、继续工作所需的关键数据。

关键词是**"交接"（Handoff）**——它不是在写会议纪要，而是在写一份让下一个人（模型）能直接上手的工作简报。

用我们的登录 Bug 场景来看：

思路拆解：

注意看压缩前后的变化——所有消息变成了 4 条。Codex 极其尊重"用户意图"，它会物理删除所有的 Assistant 回复和 Tool 相关消息，但会原封不动地保留所有 User 消息（#2 和 #10）。

随后，它插入一条伪造的 Assistant 消息，内容是一份结构化的交接总结。这份总结包含了任务目标、已完成项、关键架构决策和剩余待办。对于新模型来说，它不需要看那些大段的文件内容和测试堆栈，它只需要知道"测试已经修好了"就足够了。

自动触发与兜底 ​

当 Token 用量接近模型上下文窗口上限时，Codex 会自动触发压缩（不需要用户手动执行 /compact）。如果压缩后空间还是不够，它会退而采取更激进的"头部修剪"——直接从最早的消息开始砍，确保对话能继续下去。

笔者觉得 Codex 的方案最大的优点是直觉性：交接摘要这个概念每个职场人都能理解。缺点是它比较"一刀切"——所有 AI 回复和工具结果都被替换成一段摘要，如果那段摘要遗漏了某个关键细节，就真的找不回来了。

Claude Code：三层递进的"精密遗忘" ​

Anthropic 出品的 Claude Code 逻辑更为细腻。它不追求一步到位的物理删除，而是设计了三层逐级加强的清理机制——从轻到重，能不动 LLM 就不动 LLM。

注：Claude Code 非开源项目，以下分析基于社区逆向工程和公开资料，具体实现可能随版本变化。

第一层：工具结果修剪（无 LLM 开销） ​

这是最频繁、也最轻量的一层。不需要调用 LLM，纯粹是本地的规则引擎。它在每次请求前都会自动执行。

它的逻辑很简单：

• 始终保护最近若干个工具调用的结果（正在用的东西不能删）
• 超出保护范围的旧工具结果 → 替换为 [Old tool result content cleared] 占位符

用我们的场景来看：

这种做法极其聪明：它维护了 AI 的"心流"。AI 记得自己搜过代码（#4 的 tool_call 还在），也记得自己读过文件（#7 的 tool_call 还在），只是不记得搜到了什么、文件内容是什么。如果它之后真的需要再次查看，它会自己重新发起 read_file。

笔者认为这一层的设计极为精妙——它实现了**"选择性失忆"而非"全面遗忘"**。就像你记得去年读过一本好书，但忘了具体内容，需要的时候再翻就好。

第二层：缓存友好策略（Prompt Cache） ​

这是 Claude Code 的看家本领，也是三者中独有的差异化优势。

Anthropic 的 API 支持 Prompt Cache——如果你发给 API 的消息前缀和上一次请求相同，服务器可以复用之前的计算结果，大幅降低成本和延迟。

这意味着什么？在清理消息时，Claude Code 会尽量避免修改消息序列的前半部分。它采用"手术式"方案：只在尾部进行修整，确保消息开头部分保持绝对一致。这样做的代价是清理效率略低，但换来的是缓存命中率的最大化。

用我们的场景来看。假设经过第一层清理后，消息序列是 #1-#26（工具结果已替换为占位符）。现在上下文仍然超标，需要进一步裁剪。一个"朴素"的做法是从最早的消息开始删——但 Claude Code 不这么干：

左边的朴素策略虽然删掉了最旧的消息，看起来很合理，但代价是整个前缀都变了——API 缓存全部失效，下次请求要从头计算。右边的 Claude Code 策略则相反：它宁可少删一些，也要保证消息序列的前缀部分和上一次请求完全相同，让 Anthropic API 的 Prompt Cache 能够命中。

在长时间运行的任务中（比如你连续让 AI 帮你重构一整个模块），这种策略能带来可观的成本节省——因为每次 API 请求的大部分内容都能命中缓存，只需要为新增的尾部内容付费。

第三层：9 部分结构化 LLM 总结（最后手段） ​

当前两层都无法阻止上下文继续膨胀时，系统触发最终的全量总结。根据源码，自动压缩的触发阈值为 有效上下文窗口 - 13,000 tokens（其中有效窗口 = 模型上下文窗口 - min(最大输出 tokens, 20,000)）。

不过，即使达到了阈值，系统也不会直接跳到 LLM 总结。自动压缩触发时，系统会优先尝试 Session Memory Compact——利用 session memory（会话记忆）中已有的结构化信息来替代完整的 LLM 调用。这意味着大多数自动压缩甚至不需要 LLM 调用。只有当 session memory 路径不可用或不够时，系统才会回退到传统的 LLM 总结流程，生成一份包含 9 个固定部分的结构化摘要：

1. 用户的原始意图
2. 核心技术概念
3. 关注的文件和代码
4. 遇到的错误及修复方式
5. 解决问题的逻辑链
6. 所有用户消息的摘要
7. 待办事项
8. 当前正在做什么
9. 建议的下一步

这份摘要的要求极其严格——Prompt 中会要求模型直接引用原文关键短语，而不是全部用自己的话改写。这是为了防止"语境漂移"（模型在复述过程中微妙地偏离原意）。

用我们的场景来看：

压缩完成后，Claude Code 还会做一系列善后工作，笔者把它叫做**"状态重构"**：

• 在新对话开头注入引导语（"本次会话延续自上一段对话..."）
• 自动重新读取最近编辑过的文件（最多 5 个文件，总预算 50,000 tokens，单文件上限 5,000 tokens），确保 AI 手里有最新代码
• 重新声明工具和技能定义
• CLAUDE.md 中的项目规范作为系统提示语的一部分，始终常驻，不受压缩影响

用户还可以在手动压缩时附加自定义指令，比如 /compact Focus on API changes，引导压缩侧重于特定方向。

此外，系统还有一条被动兜底路径：当 API 返回 prompt_too_long 错误时，系统会自动启动一次反应式压缩并重试请求，确保用户不会因为上下文溢出而直接遇到错误中断。同时，为防止压缩反复失败导致的死循环，连续 3 次自动压缩失败后系统会暂停自动压缩功能。

Claude Code 的方案是三者中最复杂的，但也是最"省钱"的——大多数时候它只需要执行第一层的规则引擎清理，或者通过 Session Memory 路径完成压缩，根本不需要额外的 LLM 调用。

OpenCode：先修剪，再摘要的"阶梯治理" ​

开源界的新秀 OpenCode（源码，TypeScript + Effect-TS 实现）则提供了一种更为平衡的策略。它在 session/compaction.ts 中实现了一套阶梯式的治理流程：先用低成本手段尽可能腾空间，实在不够再动用 LLM。

第一步：Prune（标记隐藏，非物理删除） ​

OpenCode 的第一个动作不是删除，而是"标记"。它的规则非常清晰：

• 只有当修剪能释放超过 20,000 tokens 时才执行（小修小补不值得折腾）
• 始终保留最近的 40,000 tokens 作为"安全垫"（正在进行的工作不能动）
• skill 类型的工具输出永远不修剪（因为里面包含操作指令）
• 保护最近 2 个用户回合的完整内容

关键设计：和 Claude Code 的占位符替换不同，OpenCode 的修剪不是物理删除，而是给旧消息打上一个 compacted = Date.now() 的时间戳标记，让它们在后续请求中"不可见"。数据其实还在数据库里，只是被隐藏了。

关键点： 数据并没有真正丢掉。这为未来可能的历史回溯功能留下了空间——如果开发者需要审计，或者 Agent 触发了某种回溯逻辑，这些数据是可以被重新拉回上下文的。这是一个很有前瞻性的设计。

第二步：LLM 5 标题摘要 ​

如果 Prune 之后还是太臃肿，OpenCode 会用一个隐藏的、专门的 Agent（不干扰用户当前的交互）来调用 LLM 生成一份摘要。这份摘要有一个固定的 5 标题结构：

OpenCode 在摘要后有一个非常温馨的设计：它会自动重放最后一条用户消息。这能确保 Agent 的最后记忆点始终停留在用户的最新指令上，而不是停留在一段冷冰冰的摘要总结里。用户完全感知不到压缩的发生——你说的最后一句话会被重新发送，AI 继续回答，好像什么都没发生过。

另一个亮点：OpenCode 会跟随用户的语言。如果你一直用中文交流，它的摘要也会是中文的。这对非英语母语的开发者来说，是一个很友好的设计。

笔者觉得 OpenCode 的方案在三者中最"开发者友好"——代码全开源（TypeScript），架构现代（Effect-TS），非物理删除的设计为扩展留足空间。如果你想深度定制压缩行为，OpenCode 是最容易上手的。

三剑客同台竞技 ​

我们将三者的方案放在一起并排观察：

输入：26 条消息, ~15,400 tokens（同一个"修登录 bug"场景）

一些值得展开说的差异 ​

关于"要不要保留用户原话"：Codex 选择保留用户消息、只压缩模型回复，这样做的好处是 AI 永远能回看你说过什么，但代价是当用户消息本身很长时，压缩效率会打折扣。Claude Code 和 OpenCode 则选择全部压缩为摘要，更激进但更节省空间。

关于缓存：这是 Claude Code 最独特的优势。其他两家在压缩后，API 请求的内容会发生很大变化，之前的缓存基本作废。而 Claude Code 刻意维持消息前缀的稳定性，使得压缩后的请求依然能复用之前的缓存。在长时间运行的任务中，这意味着可观的成本节省。

关于"非物理删除"：OpenCode 的时间戳标记方式是个很有前瞻性的设计。虽然当前版本并没有实现历史回溯功能，但数据没有真正丢失，为未来留下了可能性。而 Codex 和 Claude Code 的压缩都是不可逆的。

最后 ​

如果用一个类比来形容这三位：

• Codex CLI 像是一个写交接单的资深员工。他直接撕掉之前的草稿纸，给你一张写的清清楚楚的现状说明，虽然简单粗暴，但非常有效。
• Claude Code 像是一个拥有精密遗忘能力的学者。他优先划掉书上的细碎批注，只有在书架实在堆不下时，才会把整本书浓缩成一页大纲。他非常在意翻书的效率（缓存）。
• OpenCode 像是一个务实的阶梯治理者。他先给旧文件打包贴上标签（隐藏），实在不行才做总结。他最贴心的地方在于，总结完后还会提醒你："你刚才最后说的是这件事对吧？"

归根结底，在 2026 年，最好的上下文管理并不是无止境地扩大 LLM 的记忆容量，而是学会如何精密地遗忘。毕竟，一个什么都记得住的 Agent，往往也最容易被噪音干扰。

参考来源：

• Codex CLI: openai/codex (参考 codex-rs/core/src/compact.rs)
• Claude Code 社区资料：
  • Claude Code System Prompts
  • Sam Saffron's Gist
  • Claude Code's Compaction Engine
  • 泄露源码仓库（非官方泄露，用于验证修订）
• OpenCode: anomalyco/opencode (参考 packages/opencode/src/session/compaction.ts)

✨文章摘要（AI生成）

笔者分享了将 Harness Engineering 知识提炼为可复用 Agent Skill 的经验。在系统阅读了 Anthropic、OpenAI、Martin Fowler、LangChain 等来源的文章后，提炼出 Harness 设计的七个核心层：项目搭建、上下文工程、约束与防护、多 Agent 架构、评估与反馈、长时间任务、诊断。最终产出的 harness-engineering 技能覆盖三大场景——新项目搭建、Agent 行为诊断、持续改进，采用渐进式披露架构。定量评估显示有技能时断言通过率 100%，无技能时 83%。核心洞察：Agent 表现不好，80% 的原因不在模型，在 Harness。

为什么写这个 ​

最近两年，笔者在使用各种AI编码助手（Claude Code、Cursor、Copilot等）的过程中，反复遇到一个问题：Agent时好时坏，虽然整体来说随着模型能力进步是向好的，但是向好的过程是曲折波动的。

有时候它写的代码完美契合项目风格，有时候它像个第一天入职的实习生——不知道项目结构、不遵守约定、还把之前商量好的决策忘得一干二净。

然后开始从 Prompt Engineering 中使用结构化、few shot、few example 等技巧，来让 AI 的输出更加稳定。 后面又使用 Context Engineering 来让 Agent 的上下文更加丰富，来让 Agent 的表现更加稳定。

最近几周，一个更系统的词汇出现了：Harness Engineering。

Agent表现不好，80%的原因不在模型，在Harness。 - Anthropic

什么是Harness？简单说：

• 模型 = CPU（算力本身）
• 上下文窗口 = RAM（工作记忆）
• Harness = 操作系统（调度、约束、反馈、文件系统——一切让CPU有效工作的基础设施）

你不会指望一个CPU在没有操作系统的裸机上高效运行。同理，你也不该指望一个模型在没有Harness的项目里稳定输出。

我学到了什么 ​

笔者系统阅读了以下来源的文章：

• Anthropic — 构建高效Agent、多Agent研究系统、长时间运行Agent的Harness设计
• OpenAI — AGENTS.md设计模式、Context Engineering最佳实践
• Martin Fowler — Harness Engineering的工程哲学（"Relocating Rigor"）
• LangChain — Agent框架 vs 运行时 vs Harness的分类学
• philschmid — 2026年Agent Harness的重要性
• 独立开发者实践 — Hermes Agent的自演化、Vue Lynx的设计笔记驱动开发
• 学术论文 — 自然语言Agent Harness的形式化研究

读完之后，我发现这些文章虽然角度各异，但核心思想收敛到了七个层：

所以我做了个技能 ​

读完这些文章，笔者意识到这些模式完全是可复用的。不管你的项目是React前端、Python后端还是Rust CLI工具——Harness的设计原则是通用的。

于是我把这些知识提炼成了一个 Agent Skill，名叫 harness-engineering。

它做什么 ​

这个技能有三个核心使用场景：

场景一：新项目搭建

当你启动一个新项目，告诉Agent"帮我搭建Harness工程"，它会：

1. 评估你的项目类型、技术栈、团队规模
2. 创建 AGENTS.md（表of目录式的Agent导航文件）
3. 建立 docs/ 目录（架构、约定、数据模型等）
4. 配置约束层（lint规则、类型检查、pre-commit hooks）
5. 设置评估与反馈机制

场景二：Agent表现不佳时的诊断

这是最有意思的场景。当你开始抱怨——

• "它怎么又犯同样的错误？"
• "它根本不遵守我们的约定！"
• "它写的代码质量太差了"

这个技能会被触发，引导Agent去诊断Harness层的缺失，而不是怪模型：

场景三：持续改进

每次发现新的可复用Harness模式，更新到技能中，让它在其他项目中也能受益。

它怎么组织的 ​

技能采用渐进式加载架构：

harness-engineering/
├── SKILL.md              # 入口文件（<60行），路由到具体参考文档
└── references/
    ├── 01-project-setup.md       # 项目搭建
    ├── 02-context-engineering.md  # 上下文工程
    ├── 03-constraints.md          # 约束与防护
    ├── 04-multi-agent.md          # 多Agent架构
    ├── 05-eval-feedback.md        # 评估与反馈
    ├── 06-long-running.md         # 长时间任务
    └── 07-diagnosis.md            # 诊断

SKILL.md本身非常精简——它就像一个路由器，根据当前场景指引Agent去读对应的参考文档。这遵循了Harness Engineering本身的原则：渐进式披露，按需加载。

几个让我印象深刻的模式 ​

有几个模式特别触动笔者，感同身受，这里单独拿出来聊聊。

"给地图，不给手册" ​

这个观点从推文中看到。传统做法是给Agent写详细的分步指令（手册），但这让Agent变得脆弱——任何偏差都会导致它不知所措。

更好的做法是给Agent一张地图：

# 不好的写法（手册）
Step 1: 打开 src/auth/login.ts
Step 2: 找到 handleLogin 函数
Step 3: 在第42行添加...

# 好的写法（地图）
Auth系统在 src/auth/。登录流程：login.ts → validate.ts → session.ts。
限流中间件在 src/middleware/rateLimit.ts——参考它的模式。
每次修改auth都要在 src/auth/__tests__/ 里加测试。

地图让Agent能自主导航，手册让它成为脆弱的执行机器。

"每犯一次错，加一条规则" ​

这个模式来自多篇文章的交叉验证。核心思想：

1. Agent犯了一个错
2. 你修复了这个错
3. 然后你加一条规则，永远阻止这类错再次发生

这条规则可以是lint规则、类型约束、测试用例，或者只是文档中的一条约定。随着时间推移，Harness积累了越来越多的规则，Agent的错误率对已知模式趋近于零。

这其实就是Martin Fowler说的 "Relocating Rigor"——把人类通过Code Review、经验、直觉实施的质量把关，迁移到自动化检查中。Agent在被检查的边界内自由运行。

Harness = 数据集 ​

这个观点来自Anthropic。每次Agent交互都是一个训练信号：

• 它尝试了什么
• 什么成功了
• 什么失败了
• 修复方案是什么

这些痕迹（traces）就是你的竞争优势。它们是让你的Harness随时间越来越好的数据——不是微调模型，而是优化操作系统。

技能评估：有没有用？ ​

笔者遵循skill-creator的流程，对这个技能做了定量评估。设计了3组测试场景，每组跑with-skill和without-skill两个版本：

有技能的版本在所有场景下都通过了全部断言。无技能的版本在"新项目搭建"场景下缺失较多——它不知道要创建AGENTS.md、不知道docs/应该怎么组织、不会设置渐进式披露的上下文架构。

当然，17%的差距不算巨大。但关键是：有技能时Agent的输出一致且完整，无技能时看运气。对于一个工程实践类技能来说，一致性比偶尔的惊艳更有价值。

怎么安装 ​

这个技能可通过 GitHub 安装：

npx skills add 10xChengTu/harness-engineering

安装后，当你在Claude Code、OpenCode或其他支持Skills的Agent中工作时：

• 启动新项目 → 技能自动触发，引导搭建Harness
• 遇到Agent质量问题 → 开始抱怨时技能会介入诊断
• 主动询问 → "帮我改进这个项目的Harness"

最后 ​

Harness Engineering目前还是一个非常早期的领域。模型在变强，今天需要的约束明天可能就多余了——所以这个技能本身也遵循一个核心原则：为删除而构建。

如果你也在用AI Agent做开发，不妨试试给你的项目加上Harness。从最简单的开始——一个AGENTS.md文件、几条lint规则、一个progress.md。然后观察Agent的表现变化。

你大概率会和笔者有同样的感受：不是模型不行，是我们没给它一个好的工作环境。

本文涉及的所有参考文章和完整技能源码，均可在GitHub 仓库中找到。

✨文章摘要（AI生成）

HUNT0 是一个面向 maker 和 indie hacker 的社区驱动发布目录，想把“发布”变成一件有仪式感、可被发现、可获得反馈的事：你可以预约发布日期，通过声望加权投票与评论拿到早期反馈，再通过榜单与 Explore（按筛选意图组织）快速发现值得关注的新产品。

v1.0.0 先把核心闭环跑通：launch → discover → vote → discuss → recap/reward。我们做了实时同步投票状态、结构化的提交流程（免费排队 + Premium Launch）、以及提醒/奖项等自动化机制，目标是减少噪音，让早期发现更“有章可循”。

一切都始于一张有点“丑”的草图：一把向前倾斜的梯子。

这张梯子草图最终成为了 HUNT0 的 logo。它提醒我们：进步是一格一格爬出来的——与其等完美，不如先把不完美的东西发出去。

这也是口号 “Ship Early, Hunt Early” 的由来：创作者尽早发布，社区才能尽早发现——去浏览、投票、讨论，帮助好产品找到第一批用户。

如果你在公开构建（build in public），欢迎来这里发布；如果你喜欢探索新东西，就从“hunt”开始。

什么是 HUNT0？ ​

HUNT0 是一个社区驱动的发布目录，让“发布”和“发现”同频发生：

• 预约发布日期，把发布变成一件明确的事件
• 通过投票与评论获得早期反馈
• 用榜单与 Explore 按时间与兴趣组织“新产品”，而不是按噪音排序

上线 v1.0.0：我们做了什么 ​

v1.0.0 先聚焦在核心闭环：launch → discover → vote → discuss → recap/reward。

1）首页榜单：“今天该看什么？” ​

首页按时间窗口组织，方便你快速扫到值得关注的内容：

• Top Products Launching Today：今天（UTC）发布的产品
• Yesterday / This Week / This Month：按更长时间窗口回顾

投票状态会在页面内 实时同步：你在任意位置给某个产品投票，页面上的所有实例会立刻一起更新，无需刷新。

2）Explore：按意图筛选，而不是靠运气 ​

Explore 支持 分类、标签（最多 10 个）、时间范围、全文搜索，并支持分页。

在相同筛选条件下，Premium Launch 会在排序上优先于免费发布——在“更需要曝光”的时刻更有效。

3）产品页：展示、访问、讨论一站式 ​

每个产品都有独立详情页，便于更深入地了解与互动：

• 核心信息与外链（Visit）
• 截图画廊与更长的产品介绍（About）
• 声望加权的投票与评论
• 榜单/奖项徽章（例如日榜/周榜/月榜 Top 3）

4）提交：免费排队 + Premium Launch ​

我们把“发布”设计成一个可控流程，而不只是贴个链接：

• Free Launch：每日容量有限（默认 10 个名额/天）
• Premium Launch：通过 Stripe Checkout 付费，获得更强曝光

如果 Premium 未完成支付，提交会以草稿形态保留在你的 dashboard，不会公开展示，直到支付成功。

提交也支持更丰富的展示信息：

• 最多 3 个分类
• 最多 10 个标签
• 联系方式/社交链接（至少 1 个）
• logo 与截图，让产品页更完整

声望系统：让贡献“有分量” ​

投票不是固定的一人一票。HUNT0 使用 Reputation → Level → Vote Weight：

• 通过参与获得声望（每日访问、投票、评论、发布）
• 等级越高，投票权重越大
• 榜单按加权投票聚合，更多反映可信贡献者的偏好

它既是激励机制，也是在早期社区里减少噪音的实用手段。

提醒与奖项：把发布当成“事件” ​

为了让发布更有“时刻感”，我们加了一些自动化：

• 发布提醒邮件：在 UTC 发布日开始前 1 小时发送
• 日榜/周榜/月榜奖项：自动计算 Top 3 并通知创作者（可选公开复盘）

开始使用 ​

• 如果你是创作者：去 Submit 预约发布日期
• 如果你想发现新产品：去 Explore 按分类/标签筛选
• 如果你想看 logo 的故事：去 About 看梯子的来源

我们会持续迭代发现、榜单和社区激励机制。Launch something, hunt something——也欢迎告诉我们哪里可以做得更好。

✨文章摘要（AI生成）

笔者在两年后重新捣鼓了一个健康类小程序，这次是对两年前用uniapp做的粗糙版本进行了全面重构。由于个人非常认同这个小程序的价值——帮助用户全面了解真实的自己，加上iOS支付限制等原因，最终决定完全免费提供给大家使用。

这次重构从UI设计开始，前端使用Vue Mini全部重写，后端也进行了不少修改。技术栈上，后端保持Nest.js、GraphQL、Prisma的组合不变，前端则大换血采用Vue Mini，主要是看中了它能用Hook+响应式简化逻辑的特性，同时避免了uniapp的各种坑。

开发过程中实现了：

• GraphQL请求封装
• JWT双token刷新+静默登录
• 小程序分包优化主包体积
• 微信支付集成（虽然最后因为iOS限制被迫去掉）

最让人心累的是各种审核流程：域名备案、小程序备案、个体工商户申请、主体变更、微信支付申请、算法备案等等，走了一圈发现iOS不允许虚拟商品内购，最终只能免费提供服务。

尽管反响不大，但总算了却了一个心愿。这个小程序通过让朋友换位思考填写问卷，结合AI智能分析，帮助用户获得更全面的自我认知，笔者认为这对个人成长方向非常重要。

始 ​

熟悉我的老老...老朋友应该都知道，这个小程序其实是我两年前做的，当时是用uniapp做的，做得还比较简陋，页面比较粗糙，逻辑上只能用我的流程通过，不然就有BUG那种哈哈。

两年前的博客在这里：两个多月捣鼓了一个健康类小程序

个人是非常认同这个小程序的价值的，确确实实希望它能够帮助到更多人全面了解真实的自己，基于此以及其他原因如支付接入iOS限制😓，所以这个小程序最终是完全免费的，如果你觉得其对你有帮助，希望能帮忙多多分享一下。

所以开始重构！这次从UI设计开始，前端用Vue Mini全部重新写了一遍，后端也修改了不少。

看 ​

先展示一下最终成果：

也可以到我顺手写的一个落地页查看功能演示：xin2.link，里面也是视频演示及小程序码可以访问

忆 ​

简单回忆一下这个小程序的背景：

无论是随时间出现的互联网、新冠疫情、短视频、网络社交媒体，还是长期以往存在的如高考、宿舍氛围、人际交往、就业压力等都无时无刻考验着青少年的心理健康，据相关研究表明，出现心理健康问题的青少年不在少数，并且一些心智成熟的成年人同样也面临着心理健康问题的煎熬。

心理健康问题危害极大，国家高度重视，出台了相关政策完善心理健康体系。

但目前的情况仍然有 3 个痛点。分别是普及难、发现难、解决难。而“互联网+心理健康系统”被多篇论文及文章指出是解决心理健康问题的重要途径之一。

• 痛点 1：如何普及心理健康教育，让每一位家长、老师、学生自己都重视起来。当所有人都能正视并重视心理健康教育的时候，这个问题就能迎刃而解。目前普遍存在的问题就是父母家长教育水平偏低，不够重视心理健康教育，更加关注孩子的学业、就业情况，忽略其本身的发展。学校虽然响应国家政策，实施了一系列活动，如心理班会，心理测评、心理咨询等，但总归趣味性较低，学生参与感较少，积极度不高，即效果较差。让每一个人都重视心理健康教育是一条漫长的道路，需要坚持，不过我们仍然可以通过发现+解决的途径来加强心理健康教育，但由此又引入了痛点 2 和痛点 3 两个新的问题。
• 痛点 2：如何发现心理健康问题。学生在填写相关心理调查问卷等时，填写时可能具有片面性和欺骗性。片面性是指由于学生本身缺少相关的心理专业知识，一些心理有问题的学生对于自身的真实情况了解程度也不高，误认为自己心理并没有任何问题；欺骗性本质上也是学生并不重视这方面的调查，认为填写它并不能帮助自己，或者以为自身最近出现的问题是暂时的，并且担心其他人知道自己“有病”，所以填写的结果也就敷衍了事，往好的方向填写。最终调查结果虽然令人满意，但学生的真实问题并没有被发现。
• 痛点 3：解决心理健康问题。优质心理健康咨询资源不足，部分落后地区甚至根本无法享受到对应的心理健康咨询资源。心理咨询师通常需要较强的专业能力，丰富的阅历与人生经验，厚积而薄发，培养一个优秀的（能解决问题的）心理咨询师成本较高，即优秀的心理咨询师资源缺乏；并且在心理咨询过程中，可能会出现线下尴尬的情况，过度暴露隐私的情况。目前对于已经发现存在心理问题的学生，大多数是沟通能力并不突出，甚至并不愿意沟通交流，所以在对其进行心理辅导时，难以了解真实情况从而对症下药，整个心理辅导过程难以开展。

起 ​

功能上，主要功能保持不变，去除了以前AI对话的功能，去除了几乎没啥用的主页等等一些冗余页面，做了一些减法，即减少工作量，又不至于过多页面拖垮用户的注意力。其次，除了以前的公式计算问卷结果之外，还增加了AI智能分析问卷结果并给出积极建议的小功能。

工程上，大致确定了一下，这次主要的模式是重构前端，后端基本框架不变，只是跟随前端需求进行变化，技术栈也有一定变化，可以看下一章节。

于是，我先使用 MasterGo 画了几个主要的页面（并非全部），之所以不画全部，一方面节约时间，另一方面其他页面也可以参考这几个主要页面来做，也无需每个页面都画出来，大致效果如下：

最终效果也不是一比一还原，做的时候也有一定的微调。

栈 ​

后端技术栈保持不变（甚至都没升级版本），还是Nest.js、GraphQL、Prisma（PostgreSQL）这一套，Nest.js和Prisma不必说，Node写后端的话的经典技术栈。

至于GraphQL，由于我的数据结构是【用户表->问卷用户多对多表->问卷表->题目表】这种结构，嵌套起来使用GraphQL来查询数据时就会特别方便。在重构过程中，很多时候连接口都不必重写，直接改改查询语句就能满足当前的查询需求了，这个在我重构过程中的一些查询变化时特别明显。

前端技术栈大换血，使用了Vue Conf 2024中提到的技术栈Vue Mini，其实如果没有这个技术栈，这次技术选型也多半会直接使用原生语法进行开发，不过既然出现了Vue Mini来增强了原生语法的逻辑层，使其可以使用Hook+响应式来简化重复逻辑及心智负担，那就拍板使用Vue Mini好了。

至于为什么不使用Uniapp：

• 一方面社区评价确实不好，很多坑，我怕...
• 又套了一层，创建了一个中间层来做Vue组件和小程序的同步，遇到问题排查时我是查微信小程序文档还是Uniapp文档呢，我菜啊～
• 其配套的一些UI组件库没看到喜欢的，而原生语法就有Vant和TDeisgn这两套较为优秀的组件库可以选择

组件库的选择，这个Vant和TDeisgn都可以，个人更偏向于TDesign的颜值。

做 ​

这里简单描述一下前端基础设施搭建和一些不涉及业务部分的逻辑，后端基础设施的搭建可以参考这个Nestjs开源模版，不过也有两年未更新了，框架的版本并不是最新的。

GprahQL的封装 ​

没找到比较靠谱的GraphQL请求库，所以就自己封装了一个请求类：

import { handleLogin } from './handleLogin';
import { BASE_URL } from '@/config';

// 定义GraphQL查询的响应类型
type GraphQLResponse<T> = {
  data?: T;
  errors?: Array<{ message: string }>;
};

// 定义wx.request的选项类型
type RequestOptions = WechatMiniprogram.RequestOption;

// 定义我们的GraphQL客户端选项
interface GraphQLClientOptions {
  url: string;
}

// 定义GraphQL变量的类型
export type Variables = Record<string, unknown>;
// Header
export type Header = Record<string, string>;

class GraphQLClient {
  private url: string;

  constructor(options: GraphQLClientOptions) {
    this.url = options.url;
  }

  async query<T>(query: string, variables?: Variables, header?: Header): Promise<T> {
    return this.request<T>({ query, variables }, header);
  }

  async mutate<T>(mutation: string, variables?: Variables, header?: Header): Promise<T> {
    return this.request<T>({ query: mutation, variables }, header);
  }

  private async request<T>(payload: { query: string; variables?: Variables; }, header: Header = {}): Promise<T> {
    await handleLogin(header);
    return new Promise((resolve, reject) => {
      const options: RequestOptions = {
        url: this.url,
        method: 'POST',
        data: payload,
        header: header,
        success: (res: WechatMiniprogram.RequestSuccessCallbackResult) => {
          const response = res.data as GraphQLResponse<T>;
          if (response.errors && response.errors.length > 0) {
            reject(new Error(response.errors[0].message));
          } else if (response.data) {
            resolve(response.data);
          } else {
            reject(new Error('GraphQL response contains no data and no errors.'));
          }
        },
        fail: (err: WechatMiniprogram.GeneralCallbackResult) => {
          reject(new Error(`Network error: ${err.errMsg}`));
        }
      };

      wx.request(options);
    });
  }
}

export const graphQLClient = new GraphQLClient({
  url: BASE_URL
});
export default graphQLClient;

JWT 双token刷新+静默登录 ​

基本思路就是授权token -> 刷新token -> 登录；放在封装好的graphql请求函数里面。

• 如果有access token，判断它的exp字段是否过期，没有过期就直接请求
• 过期了就refresh token后再请求
• refresh token过期就执行登录请求
• 双token的好处，登录会额外调用一次外部接口，请求会更慢，所有尽量不使用登录接口

稍微需要注意的就是为了避免无限递归，需要做一个简单的标志，就是在refresh和login请求时，不执行这段逻辑，直接请求。

同时我这里增加了一个exp字段方便客户端直接判断token是否过期，而不是多请求一次服务器返回401才知道授权失败。

import { getExpireInPayload, getToken, setToken } from "@/utils/auth";
import { useUserInfo } from "@/hooks/useUserInfo";
import { login, refresh } from "./auth";
import { Header } from "./request";

let isSkip = false;

// 请求拦截器：实现JWT 双token刷新+静默登录
export const handleLogin = async (header: Header) => {
  if (isSkip) {
    return header;
  }

  const loginAndSetData = async () => {
    try {
      isSkip = true; // 避免递归栈溢出
      const { code } = await wx.login();
      const { accessToken, refreshToken, user } = (await login({ data: { code } }));
      // save token
      header.Authorization = `Bearer ${accessToken}`;
      setToken("accessToken", accessToken);
      setToken("refreshToken", refreshToken);
      // save userInfo
      const { setUserInfo } = useUserInfo();
      setUserInfo(user);
    } catch (error) {
      void wx.showToast({
        title: "登录失败，请检查网络并重试",
        icon: "none",
      });
      console.error('[APP ERROR] - 登录失败: ', error);
    } finally {
      isSkip = false;
    }
  }
  // 0. 获取用户信息, 如果没有用户信息则登录
  const { userInfo } = useUserInfo();
  if (!userInfo) {
    await loginAndSetData();
    return header;
  }

  const timestamp = Math.ceil(+new Date().getTime() / 1000); //获取当前的时间戳

  // 1. access部分
  const accessToken = getToken("accessToken"); // 获取身份验证令牌
  const expInAccessToken = getExpireInPayload(accessToken);
  // accessToken未过期，直接加入请求头请求
  if (timestamp < expInAccessToken) {
    header.Authorization = `Bearer ${accessToken}`;
    return header;
  }

  // 2. refresh部分
  const lastRefreshToken = getToken("refreshToken");
  const expInRefreshToken = getExpireInPayload(lastRefreshToken);
  // refreshToken未过期，刷新Token
  if (timestamp < expInRefreshToken) {
    try {
      isSkip = true; // 避免递归栈溢出
      const { accessToken, refreshToken } = (await refresh({ token: lastRefreshToken }));
      // save
      header.Authorization = `Bearer ${accessToken}`;
      setToken("accessToken", accessToken);
      setToken("refreshToken", refreshToken);
    } catch (error) {
      void wx.showToast({
        title: "登录失败，请检查网络并重试",
        icon: "none",
      });
      console.error('[APP ERROR] - 登录失败: ', error);
    } finally {
      isSkip = false;
    }
  } else {
    // 3. refreshToken过期，需要重新登录
    await loginAndSetData();
  }

  return header;
}

小程序分包减少主包体积 ​

由于这个小程序依赖于echats以及一个拼音库，体积较大且不是在tab页使用的，所以分包很有必要。

这是我的分包设置：

  "subPackages": [
    {
      "root": "analytics-package",
      "name": "analytics",
      "pages": [
        "pages/analytics/index"
      ]
    },
    {
      "root": "friend-package",
      "name": "friend",
      "pages": [
        "pages/friend-select/index"
      ]
    },
    {
      "root": "questionnaire-package",
      "name": "questionnaire",
      "pages": [
        "pages/questionnaire-fill/index",
        "pages/questionnaire-success/index",
        "pages/questionnaire-result/index"
      ]
    },
    {
      "root": "user-package",
      "name": "user",
      "pages": [
        "pages/update-profile/index",
        "pages/help-center/index"
      ]
    }
  ],
  "preloadRule": {
    "pages/questionnaire/index": {
      "network": "all",
      "packages": ["questionnaire", "analytics"]
    },
    "pages/mine/index": {
      "network": "all",
      "packages": ["user"]
    },
    "analytics-package/pages/analytics/index": {
      "network": "all",
      "packages": ["friend"]
    }
  },

很简单，其实只要告诉AI你的页面依赖情况，然后它就自动给你分好了，最后再叫AI全局搜索一下路径跳转，将相应路径修改为分包之后的路径即可。

微信支付的实现 ​

基本流程 ​

参考：小程序微信支付接入指引，小程序支付API文档

不得不说对比起来Stripe的接入是真方便，微信支付首先没有NodeJS、Python等的官方SDK，所有的加密解密安全等与业务无关的代码还需要自己再写一遍，以及微信支付没有测试环境，所以测试时只能通过真实环境1分钱1分钱地测试...

这里引用一张官方的泳道图：

不过目前仅通过自己的测试，由于iOS虚拟商品支付的限制，导致无法通过审核，并没有真正上线测试，所以下方代码仅供参考。

后端实现 ​

这是我的支付service：

import {
  Injectable,
  Logger,
  BadRequestException,
  NotFoundException,
} from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { PrismaService } from 'nestjs-prisma';
import { CreatePaymentInput } from './dto/create-payment.input';
import { UpdatePaymentInput } from './dto/update-payment.input';
import { Payment } from './models/payment.models';
import {
  WechatPaymentResponse,
  WechatPayNotifyResult,
} from './dto/wechat-payment.dto';
import {
  PaymentStatus,
  PaymentType,
  PAYMENT_PRICES,
  WechatPayConfig,
} from './dto/payment-config';
import { v4 as uuidv4 } from 'uuid';
import { addMonths, addYears } from 'date-fns';
import { HttpService } from '@nestjs/axios';
import * as crypto from 'crypto';
import { UsersService } from '../users/users.service';
import { RoleEnum } from '../common/enums/role.enum';
import { firstValueFrom } from 'rxjs';

@Injectable()
export class PaymentsService {
  private readonly logger = new Logger(PaymentsService.name);
  private wechatConfig: WechatPayConfig;

  constructor(
    private prisma: PrismaService,
    private configService: ConfigService,
    private httpService: HttpService,
    private usersService: UsersService
  ) {
    // 初始化微信支付配置
    this.wechatConfig = {
      mchid: this.configService.get<string>('WECHAT_PAY_MCHID') || '',
      appid: this.configService.get<string>('WECHAT_PAY_APPID') || '',
      notifyUrl: this.configService.get<string>('WECHAT_PAY_NOTIFY_URL') || '',
      apiV3Key: this.configService.get<string>('WECHAT_PAY_API_V3_KEY') || '',
      serialNo: this.configService.get<string>('WECHAT_PAY_SERIAL_NO') || '',
      privateKey: Buffer.from(
        this.configService.get<string>('WECHAT_PAY_PRIVATE_KEY_BASE64') || '',
        'base64'
      ).toString('utf8'),
    };

    // 校验配置是否完整
    if (
      !this.wechatConfig.mchid ||
      !this.wechatConfig.appid ||
      !this.wechatConfig.notifyUrl
    ) {
      this.logger.warn('微信支付配置不完整，部分功能可能无法正常工作');
    }
  }

  /**
   * 创建支付订单
   */
  async create(
    userId: string,
    createPaymentInput: CreatePaymentInput
  ): Promise<Payment> {
    const { type } = createPaymentInput;

    // 获取支付金额配置
    const priceConfig = PAYMENT_PRICES.find((p) => p.type === type);
    if (!priceConfig) {
      throw new BadRequestException('无效的支付类型');
    }

    // 生成商户订单号
    const outTradeNo = `PAY${Date.now()}${Math.floor(Math.random() * 1000)}`;

    // 创建支付记录
    const payment = await this.prisma.payment.create({
      data: {
        userId,
        type,
        outTradeNo,
        amount: priceConfig.amount,
        description: priceConfig.description,
        status: PaymentStatus.PENDING,
      },
    });

    return payment as Payment;
  }

  /**
   * 创建JSAPI支付参数
   */
  async createWechatPayment(
    userId: string,
    createPaymentInput: CreatePaymentInput,
    openid: string
  ): Promise<WechatPaymentResponse> {
    // 创建支付记录
    const payment = await this.create(userId, createPaymentInput);

    try {
      // 调用微信支付接口
      const result = await this.createWechatJsapiPay(payment, openid);
      return result;
    } catch (error) {
      // 如果微信支付下单失败，更新订单状态
      await this.prisma.payment.update({
        where: { id: payment.id },
        data: { status: PaymentStatus.FAILED },
      });

      this.logger.error(`微信支付下单失败: ${error.message}`, error.stack);
      throw new BadRequestException('支付下单失败，请稍后重试');
    }
  }

  /**
   * 调用微信JSAPI支付接口
   */
  private async createWechatJsapiPay(
    payment: Payment,
    openid: string
  ): Promise<WechatPaymentResponse> {
    // 构建微信支付请求数据
    const timestamp = Math.floor(Date.now() / 1000).toString();
    const nonceStr = uuidv4().replace(/-/g, '');

    // 微信支付V3接口地址
    const url = 'https://api.mch.weixin.qq.com/v3/pay/transactions/jsapi';

    // 构建请求数据
    const requestData = {
      appid: this.wechatConfig.appid,
      mchid: this.wechatConfig.mchid,
      description: payment.description,
      out_trade_no: payment.outTradeNo,
      notify_url: this.wechatConfig.notifyUrl,
      amount: {
        total: payment.amount,
        currency: 'CNY',
      },
      payer: {
        openid: openid,
      },
    };

    // 计算请求签名
    const nonce = nonceStr;
    const method = 'POST';
    const body = JSON.stringify(requestData);

    // 构造签名字符串
    const message = `${method}\n${
      new URL(url).pathname
    }\n${timestamp}\n${nonce}\n${body}\n`;
    const signature = this.sign(message);

    // 构造Authorization头
    const authorization = `WECHATPAY2-SHA256-RSA2048 mchid="${this.wechatConfig.mchid}",nonce_str="${nonce}",signature="${signature}",timestamp="${timestamp}",serial_no="${this.wechatConfig.serialNo}"`;

    try {
      // 发送请求到微信支付API
      const response = await firstValueFrom(
        this.httpService.post(url, requestData, {
          headers: {
            'Content-Type': 'application/json',
            Accept: 'application/json',
            Authorization: authorization,
          },
        })
      );

      const prepay_id = response.data.prepay_id;

      // 生成小程序调起支付的参数
      const paymentParams = this.buildMiniProgramPayment(prepay_id);
      return paymentParams;
    } catch (error) {
      this.logger.error(`微信支付API调用失败: ${error.message}`, error.stack);
      throw new BadRequestException('支付请求失败，请稍后再试');
    }
  }

  /**
   * 生成小程序调起支付的参数
   */
  private buildMiniProgramPayment(prepayId: string): WechatPaymentResponse {
    const timestamp = Math.floor(Date.now() / 1000).toString();
    const nonceStr = uuidv4().replace(/-/g, '');
    const packageStr = `prepay_id=${prepayId}`;

    // 构造签名字符串
    const message = `${this.wechatConfig.appid}\n${timestamp}\n${nonceStr}\n${packageStr}\n`;
    const paySign = this.sign(message);

    return {
      appId: this.wechatConfig.appid,
      timeStamp: timestamp,
      nonceStr: nonceStr,
      package: packageStr,
      signType: 'RSA',
      paySign: paySign,
    };
  }

  /**
   * RSA签名
   */
  private sign(message: string): string {
    // 从私钥文件中读取私钥
    const privateKey = this.wechatConfig.privateKey;

    // 创建签名对象
    const sign = crypto.createSign('RSA-SHA256');
    sign.update(message);

    // 签名并返回 Base64 编码结果
    return sign.sign(privateKey, 'base64');
  }

  /**
   * 处理微信支付回调通知
   */
  async handlePayNotify(
    headers: Record<string, string>,
    body: string | any
  ): Promise<{ code: string; message: string }> {
    try {
      // 解析通知数据 - 检查 body 是否已经是对象
      let notifyData: any;
      this.logger.log('body', body);
      if (typeof body === 'string') {
        notifyData = JSON.parse(body);
      } else {
        // body 已经是解析后的对象
        notifyData = body;
      }

      // 验证签名
      // 注：实际项目中，这里需要验证微信支付通知的签名，确保通知合法性
      // 由于涉及到证书和复杂的解密步骤，这里简化处理

      // 验证通知信息
      const resource = notifyData.resource;
      const ciphertext = resource.ciphertext;
      const nonce = resource.nonce;
      const associatedData = resource.associated_data || '';

      // 解密数据
      const decryptedData = this.decryptAes256Gcm(
        ciphertext,
        this.wechatConfig.apiV3Key,
        nonce,
        associatedData
      );

      const payResult = JSON.parse(decryptedData) as WechatPayNotifyResult;

      // 查找对应的支付订单
      const payment = await this.prisma.payment.findFirst({
        where: { outTradeNo: payResult.out_trade_no },
      });

      if (!payment) {
        this.logger.error(`支付回调：找不到订单 ${payResult.out_trade_no}`);
        return { code: 'FAIL', message: '订单不存在' };
      }

      // 判断支付状态
      if (payResult.trade_state === 'SUCCESS') {
        // 更新支付状态
        const user = await this.updatePaymentAndUser(payment.id, payResult);

        this.logger.log(
          `支付成功：用户 ${user.id} 支付订单 ${payment.outTradeNo}，金额 ${
            payResult.amount.total / 100
          } 元`
        );
        return { code: 'SUCCESS', message: 'OK' };
      } else {
        // 处理其他支付状态
        await this.prisma.payment.update({
          where: { id: payment.id },
          data: {
            status: PaymentStatus.FAILED,
          },
        });

        this.logger.warn(
          `支付未成功：订单 ${payment.outTradeNo}, 状态 ${payResult.trade_state}`
        );
        return { code: 'SUCCESS', message: 'OK' };
      }
    } catch (error) {
      this.logger.error(`处理支付回调出错: ${error.message}`, error.stack);
      return { code: 'FAIL', message: '回调处理失败' };
    }
  }

  /**
   * 更新支付记录和用户信息
   */
  private async updatePaymentAndUser(
    paymentId: string,
    payResult: WechatPayNotifyResult
  ) {
    // 使用事务确保数据一致性
    return await this.prisma.$transaction(async (tx) => {
      // 1. 更新支付记录
      const payment = await tx.payment.update({
        where: { id: paymentId },
        data: {
          status: PaymentStatus.SUCCESS,
          paidAt: new Date(payResult.success_time),
        },
      });

	// 略一部分，更新用户表的VIP字段

      return updatedUser;
    });
  }

  /**
   * AES-256-GCM 解密
   */
  private decryptAes256Gcm(
    ciphertext: string,
    key: string,
    nonce: string,
    associatedData: string
  ): string {
    // 使用 base64 解码密文
    const ciphertextBuffer = Buffer.from(ciphertext, 'base64');

    // 创建解密器
    const decipher = crypto.createDecipheriv(
      'aes-256-gcm',
      key,
      Buffer.from(nonce, 'utf8')
    );

    // 设置关联数据
    decipher.setAAD(Buffer.from(associatedData, 'utf8'));

    // 假设密文的最后16字节是认证标签
    const authTagLength = 16;
    const authTag = ciphertextBuffer.slice(
      ciphertextBuffer.length - authTagLength
    );
    const actualCiphertext = ciphertextBuffer.slice(
      0,
      ciphertextBuffer.length - authTagLength
    );

    // 设置认证标签
    decipher.setAuthTag(authTag);

    // 解密
    let decrypted = decipher.update(actualCiphertext);
    decrypted = Buffer.concat([decrypted, decipher.final()]);

    return decrypted.toString('utf8');
  }

  /**
   * 查询所有支付记录
   */
  findAll() {
    return this.prisma.payment.findMany();
  }

  /**
   * 查询单个支付记录
   */
  findOne(id: string) {
    return this.prisma.payment.findUnique({
      where: { id },
    });
  }

  /**
   * 查询用户的支付记录
   */
  findByUser(userId: string) {
    return this.prisma.payment.findMany({
      where: { userId },
      orderBy: { createdAt: 'desc' },
    });
  }

  /**
   * 更新支付记录
   */
  update(id: string, updatePaymentInput: UpdatePaymentInput) {
    return this.prisma.payment.update({
      where: { id },
      data: updatePaymentInput,
    });
  }

  /**
   * 删除支付记录
   */
  remove(id: string) {
    return this.prisma.payment.delete({
      where: { id },
    });
  }
}

有两个主要的接口暴露出去：

• 一个是支付成功的回调接口，这个接口调用上述service的handlePayNotify进行处理即可；
• 还有一个是创建支付时的接口，这个接口调用上述service的createWechatPayment即可

前端实现 ​

这是前端支付创建流程：

  const handlePay = async (type: number, description: string) => {
    isPayLoading.value = true;
    try {
      const paymentData = await createWechatPayment({
        data: {
          type,
          description
        }
      });

      await new Promise<void>((resolve, reject) => {
        wx.requestPayment({
          appId: paymentData.appId,
          nonceStr: paymentData.nonceStr,
          package: paymentData.package,
          paySign: paymentData.paySign,
          signType: paymentData.signType as 'MD5' | 'HMAC-SHA256' | 'RSA',
          timeStamp: paymentData.timeStamp,
          success: async () => {
            showSuccess('支付成功');

            // 支付成功后刷新用户信息
            try {
              const latestUserInfo = await getUserInfo();
              setUserInfo(latestUserInfo);
            } catch (error) {
              console.error('刷新用户信息失败:', error);
            }

            resolve();
          },
          fail: (err) => {
            console.error('支付失败:', err);
            showError('支付失败');
            reject(new Error(err.errMsg || '支付失败'));
          }
        });
      });
    } catch (error) {
      console.error('创建支付订单失败:', error);
      showError('创建订单失败');
    } finally {
      isPayLoading.value = false;
    }
  };

就两步：

• 调用后端的创建订单接口返回一堆数据
• 然后通过这堆数据调用微信支付的拉取调用接口即可拉取微信支付

提交时小程序切换后台导致请求取消问题修复 ​

这个是上线之后用户反馈的一个前端体验的问题。

背景是：由于问卷提交时，有较长的上下文发送给AI进行分析以及对应问卷的一个计算公式需要计算，所以在提交时花费时间较长。

这时候可能有一些用户就会切换小程序到后台，从而导致微信请求被取消，从而触发了保存失败的提示（实际后端已经执行成功了）

具体可以看微信小程序的这篇文章：微信小程序的运行机制

即5秒之后如果接口没有请求完成，就会被切换到挂起状态从而在前端取消对应的请求，从而触发报错信息，以及留在提交页面，保存按钮也是可以继续触发的。所以我做了一个简单的判断，以保证用户的体验：

catch (error) {
      // 因为进入问卷页时就会检查更新权限，如果这里报错，说明挂起之后重新提交了，提示用户提交成功
      if (error instanceof Error && error.message === 'You can only update once per day') {
        // showWarning('24h内你已经提交过一次了');
        wx.nextTick(() => {
          void wx.reLaunch({
            url: '/pages/questionnaire/index',
            success: () => {
              showWarning('24h内你已经提交过一次了');
            }
          });
        })
      } else {
        showError('保存失败，请稍后重试');
        console.error('[APP ERROR] - 保存问卷填写结果失败: ', error);
      }

此时，如果用户提交后从后台返回该小程序，如果因为挂起状态导致请求取消，再次提交时，根据后端返回是否提交过的信息，判断返回首页并友好提示。

困 ​

其实主要就是遇到了各种审核的问题，导致走一步，等一步，然后热情被浇灭了，又得过一阵才会鼓起劲再来做一部分，从而导致了这个小程序历经两年才重构完成。

来，我们来数一数：

1. 首先是域名的备案，因为小程序需要https接口，所以不能直接使用ip地址进行请求（当然本身不安全，所以需要域名，理解）
2. 然后自然而然需要经过腾讯云、工信局、本地公安的审核
3. 接下来微信小程序本身的备案（还要花钱，毕竟是外包给其他公司的，我们理解）
4. 备案过程中，打电话询问了小程序的情况，发现我有出售服务，所以被打回了，因为我是个人资质，不能出售商品
5. 好，接下来继续申请个体工商户，同样的，准备各种资料，被打回了两次终于审核成功拿到营业执照
6. 然后又提交一堆表单，打印了小程序主体变更书，然后提交审核将小程序的主体变更为了这个个体户
7. 再然后申请微信支付
8. 因为我需要用大模型来分析结果，所以又做了算法备案申请了小程序的深度合成类目
9. 写代码上线
10. 结果在提交了4-5个版本之后（前几个版本也是携带着微信支付的代码的），下一个版本审核失败，因为有虚拟商品的购买，iOS早在2020年左右就不允许微信小程序内购虚拟商品了
11. 没有办法，走过来一场空，又把微信支付相关代码全部去掉，最终加了点封面广告和提交等待时的弹窗广告以维持Token费用，最终免费给大家使用了

心累啊～

终 ​

好在最终仅供多轮测试，成功上线，虽然反响不大，但总算了却了一个心愿，查了下git，最近1个月光是前端代码，就有近100次commit，感谢Vibe Coding啊～

后端不用多说，Vibe Coding时AI对于Nestjs的代码还是很熟悉的；而前端 Vibe coding 时只需告诉AI，逻辑层使用Vue3增强，视图层使用原生语法，效果就还不错～

整体还是非常推荐使用Vue Mini来进行开发小程序的，一个是拥有TS、Hook、响应式等现代化的写法，另外一个还是保留着原生小程序语法的生态，且没有额外封装一层导致的坑（复杂度）

接下来会继续小步完善该小程序的功能，比如排行榜功能等等...

最后，欢迎使用该小程序：xin2.link，里面也是视频演示及小程序码可以访问。

通过这个小程序，你可以让朋友换位思考在你的角度填写问卷，从而得到更加全面的自我了解（自我评价+他人评价），以及AI会给出智能分析及积极建议，让大家和朋友一起更加了解自己，了解自己究竟是什么样的一个人，我认为这对今后的成长方向是非常重要的。

谢谢大家看到了这么多碎碎念。

原文链接：GPT-4o Image Generation Guide

Turbo0是一个内容创作者工具目录，你可以在Turbo0.com里面找到更多有关图片编辑的工具和资源～

✨文章摘要（AI生成）

笔者整理了一份详尽的GPT-4o图像生成风格指南，涵盖了多种独特的艺术风格和应用场景。主要包括：

经典艺术风格：吉卜力动画风格、赛博朋克风格、水彩画风格、油画风格、浮世绘风格等

现代创意风格：3D Q版角色、手绘简笔画、像素艺术、Low Poly低多边形、手绘高亮信息卡片等

这些风格可应用于品牌设计、头像生成、儿童绘本、产品原型等多个实际场景。文中还分享了发现新玩法的四个秘籍：利用搜索引擎、社交媒体、专业平台以及反向分析法。通过这些方法，用户可以不断探索和创新，提升提示词使用技巧，创造出更多独特的视觉效果。

本文为读者提供了一个系统化的GPT-4o图像生成参考指南，既可作为入门教程，也适合进阶学习使用。

风格 ​

Studio Ghibli风格 (Studio Ghibli Style) ​

Redraw in the style of Ghibli anime​（将照片重绘成吉卜力动画风格）

Cyberpunk风格 (赛博朋克风格) ​

A rainy street in a future city, full of neon signs, cyberpunk style.（一个充满霓虹灯的未来都市雨夜街景，赛博朋克风格）

中式婚礼 ​

将照片里的两个人转换成Q版 3D人物，中式古装婚礼，大红颜色，背景“囍”字剪纸风格图案。 服饰要求：写实，男士身着长袍马褂，主体为红色，上面以金色绣龙纹图案，彰显尊贵大气 ，胸前系着大红花，寓意喜庆吉祥。女士所穿是秀禾服，同样以红色为基调，饰有精美的金色花纹与凤凰刺绣，展现出典雅华丽之感 ，头上搭配花朵发饰，增添柔美温婉气质。二者皆为中式婚礼中经典着装，蕴含着对新人婚姻美满的祝福。 头饰要求： 男士：中式状元帽，主体红色，饰有金色纹样，帽顶有精致金饰，尽显传统儒雅庄重。 女士：凤冠造型，以红色花朵为中心，搭配金色立体装饰与垂坠流苏，华丽富贵，古典韵味十足。

手绘简笔画风格 ​

先把图片人物变成手绘简笔画风格 然后把简笔画按照吐舌头、微笑、皱眉、惊讶、思考、眨眼生成一系列表情包

手绘插画风格 ​

Create concise, visually structured notes on the topic '{{topic}}'. Notes must fit clearly within a {{orientation}} layout (horizontal/vertical), featuring: - Moderate Font Size: Comfortable readability. - Clear Structure: - Main points highlighted with "background colors" or "wavy underlines~". - Regular notes in standard ink. - Emphasis notes in a different ink color. - Illustrations: - Include relevant sketches or hand-drawn style illustrations. - Allow fountain pen-style doodles or annotations directly on illustrations. - Annotations: - Simulate notes, corrections, and additional quirky doodles resembling spontaneous annotations, using marker pen style. - Incorporate collage-style photo extracts relevant to the topic, annotated or doodled upon. - Language Text Accuracy Constraint (Strict): - When generating text in '{{language}}', abide by recognized dictionaries and standard grammar rules. - For languages like 中文 (Chinese) or others with complex scripts: - Ensure each character or symbol is correct, standard, and used appropriately. - Double-check stroke order, avoid non-existent variants, and verify usage before finalizing the notes. User Settings: - Topic: 孩子教育 - Orientation: Vertical - Language: 中文 - Color Scheme: highlight style. - Illustration Style: Detailed hand-drawn

3D Q版风格 ​

将场景中的角色转化为3D Q版风格，同时保持原本的场景布置和服装造型不变。比例 2:3

我的世界像素风格 ​

Make this in minecraft voxel style

麦金塔电脑 ​

Create an image in pixel art style of an original Macintosh computer with keyboard. On the screen is the uploaded image opened in MacPaint, converted to black and white. ratio is 2:3

3D Q版弥勒佛形象 ​

3D Q版弥勒佛形象

3D手办风格 ​

转换为3D手办风格

工作室风格 ​

将右边的人物风格化为左边的图像。人物应该稍微转身，像左侧照片中的人一样。穿着黑色衬衫。被柔和的工作室灯光照亮，背景为深色，创造出焦外效果，突出显示如面部纹理或细纹等细节。他们的目光反射出平静，凝视着远方。肖像摄影。使用 Sony Alpha A7 III 和 f/2 镜头拍摄。照片真实感，8k 分辨率。方形画幅比例（1:1）。

APP Icon ​

Create a 3D-style chibi app icon character with a cute, toy-like appearance. The character should have large expressive eyes, a small smile, and detailed, glossy features like a real physical toy. Use a soft, vibrant lighting style to give it a polished, high-quality finish. The character should slightly exceed the app icon’s frame to enhance the 3D effect and playfulness. Style should feel collectible and adorable, like a miniature figure or Nendoroid.

键盘微缩场景 ​

一幅等距3D插画描绘了被掀开的键盘键帽下，一个微型玩家正坐在迷你驾驶舱里打游戏，并将键帽内侧当作发光的屏幕。带有轻微的 3D 质感和些许塑化感，使整个场景如同一个为游戏玩家量身定做的、极其精巧的立体模型。

微缩世界 ​

一幅极简风格的等距 3D 插画，描绘了一个隐藏在老旧的米色电脑主机箱（典型的 90 年代末/2000 年代初办公室风格，ATX 结构）内部的微型、极致宁静的解压绿洲——一个日式枯山水庭院。

外部特征： 主机箱外观是经典的米白色或淡黄色塑料，可能带有软盘驱动器插槽、光驱托盘、遍布灰尘的散热格栅、圆形的电源按钮，甚至侧面贴着一张褪色的“Property of...”资产标签。整体呈现出一种被遗忘的、充满年代感的办公室设备外观。

内部场景： 打开的主机箱侧板（或移除侧板后的内部空间）被改造成一个微缩的枯山水庭院。大部分空间被精心铺设的细白沙所覆盖，沙面上用迷你耙子仔细地耙出了代表水波的纹路（波纹，hamon）。几块形态各异、经过挑选的微型深色岩石（象征山岛）错落有致地摆放其间。一小片翠绿的仿真苔藓覆盖在某个角落的“岩石”边。或许还有一个用细铜线和电子元件巧妙改造的迷你“添水”（鹿威し）装置，静静地立着。

人物： 一个穿着皱巴巴衬衫、可能还打着松垮领带的微型“社畜”小人，正平静地跪坐在沙园的一角，手持一把极其小巧的木质耙子，眼神专注地望着眼前的沙纹，仿佛在进行一场心灵的冥想。

细节与氛围： 光线主要从主机箱顶部的散热口或侧面的缝隙中以光束的形式照射进来，穿过内部可能存在的、象征性的微尘，在沙面和岩石上投下清晰而柔和的阴影。光线可能是模拟办公室的冷色日光灯，但在庭院区域被内部氛围中和得更为柔和、宁静。整个场景色调以沙子的白色、岩石的深灰、苔藓的绿色以及背景中主机内部零件的金属/塑料原色为主，形成一种素雅、克制的对比。营造出一种极致的平和、专注与逃离现实的禅意氛围。

整体感受： 带有轻微的 3D 质感和些许塑化感，如同一个藏在冰冷科技外壳下的温暖秘密、一个精巧的桌面立体模型。这个场景在象征着工作压力与束缚的电脑主机内部，构建了一个代表内心平静与精神自由的禅意空间，形成了强烈的视觉与情感对比。非常适合需要片刻宁静的现代都市人、办公室职员、微缩模型与日式美学爱好者，以及欣赏探讨工作、生活与内心世界关系的数字艺术作品的人们。

Low Poly风格 (低多边形风格) ​

A minimalist 3D island floating in space, low-poly design with pastel colors.（一座漂浮在太空中的极简3D岛屿，低多边形设计，柔和马卡龙配色）

景区浏览笔记 ​

请生成一张图片，模拟在一张略带纹理的纸张（比如米黄色或浅棕色）上手写的关于景区 请在此处替换为景区名称 的讲解笔记。图片应呈现旅行日志/拼贴画风格，包含以下元素：

用手写字体（比如蓝色或棕色墨水）书写景区名称、地理位置、最佳游览季节、以及一两句吸引人的标语或简介。 包含几个主要看点或特色的介绍，使用编号列表或项目符号（例如：列举2-3个具体看点，如“奇特的岩石形态”，“古老的传说”，“独特的植物”等），并配有简短的手写说明。 用红色笔迹或其他亮色圈出或用箭头指向特别推荐的地点或活动（例如 列举1-2个推荐项）。 穿插一些与景区特色相关的简单涂鸦式小图画（例如：根据景区特色想1-2个代表性图画，如山峰轮廓、特色动植物、标志性建筑等]=）。

点缀几张关于该景区的、看起来像是贴上去的小幅照片（可以是风景照、细节照，风格可以略显复古或像宝丽来照片）。 整体感觉要像一份由热情导游或资深游客精心制作的、生动有趣的个人导览手记。

手绘高亮信息卡片 ​

创作一张手绘风格的信息图卡片，比例为9:16竖版。卡片主题鲜明，背景为带有纸质肌理的米色或米白色，整体设计体现质朴、亲切的手绘美感。 卡片上方以红黑相间、对比鲜明的大号毛笔草书字体突出标题，吸引视觉焦点。文字内容均采用中文草书，整体布局分为2至4个清晰的小节，每节以简短、精炼的中文短语表达核心要点。字体保持草书流畅的韵律感，既清晰可读又富有艺术气息。 卡片中点缀简单、有趣的手绘插画或图标，例如人物或象征符号，以增强视觉吸引力，引发读者思考与共鸣。 整体布局注意视觉平衡，预留足够的空白空间，确保画面简洁明了，易于阅读和理解。

<h1><span style="color:red">「认知」</span>决定上限 <span style="color:red">「圈子」</span>决定机会</h1> - 你赚不到「认知」以外的钱， - 也遇不到「圈子」以外的机会。

Vaporwave风格 (蒸汽波风格) ​

Redo this image in the Vaporwave style, neon pinks and purples, chrome textures, digital sunset gradients, 1980s retrofuturistic aesthetic...（将此图像重新制作成蒸汽波风格，带有霓虹粉紫色、铬合金质感、数字夕阳渐变和80年代未来复古美学…）

像素艺术风格 (Pixel Art Style) ​

请生成一张8-bit像素风格的游戏场景

水彩画风格 (Watercolor Style) ​

Turn it into Hand-Painted Watercolor.

Innsmouth Shadow Notes ​

Generate an image with an aspect ratio of 2:3 and use English for the text within the image. This image is to simulate a personal notes page created by a reader for the novel The Shadow over Innsmouth. Style: Collage/scrapbook aesthetic, hand-drawn elements mixed with pasted items on a textured paper background (e.g. like a Moleskine notebook or vellum). Please include the following elements: HANDWRITTEN QUOTES: A few classic or impactful English sentences from a novel, written in a clear but handwritten font with a personal touch. CHARACTER DRAWINGS: Simple doodle-style headshots of 2-3 main characters, not necessarily very realistic, but more like quick impressionistic captures. CHARACTER RELATIONSHIPS DIAGRAM: Arrows drawn between the character doodles with short handwritten English text labels describing their relationships (e.g. "Siblings", "Lovers", "Mentor & Student", "Rivals"). PASTED CORNER OF PAGE: A small, realistic-looking piece that simulates a corner torn or cut from an actual novel page (on which some printed English text can be seen) that looks like it was taped or glued to the notes page. (Optional) Annotations: Possibly small handwritten notes or question marks next to quotes or characters. Layout: Elements should be arranged organically, perhaps overlapping slightly, to create the feel of a frequently used personal journal page. OVERALL FEEL: Thought provoking, analytical, personal, visually appealing.

油画风格 (Oil Painting Style) ​

A peaceful European village at sunset, in oil painting style.（日落时分宁静的欧洲村庄，油画风格）

美式漫画风格 (Comic Book Style) ​

A masked hero jumping from a rooftop, comic book style with bold outlines and dialogue bubbles.（一位戴面具的英雄从屋顶跃下，漫画风格，粗线条描边并带对白气泡）

日系动漫风格 (Anime Style) ​

Turn it into Anime style.（转换为日系动画风格）

浮世绘风格 ​

将此侦探电影场景转为传统日本浮世绘版画风格，保留戏剧性阴影和人物表情，适应传统颜料调色板。

超现实主义/抽象构图 ​

创建一个圆形图像，包含12个对象的螺旋排列，背景为深空，包括水晶沙漏、机械蝴蝶等。

一些场景 ​

• 品牌设计与营销视觉：包括Logo、商品包装、宣传海报等
• 头像生成与个人形象
• 儿童绘本插图
• 产品原型与概念设计
• 插画创作与艺术设计
• 室内设计与装修布局
• 电影分镜与情节板
• 社交媒体封面图
• 游戏角色设定与草图
• 视觉风格转换与图像混合
• 教学演示与图示说明

如何发现 GPT-4o 画图新玩法的 ​

推荐看看宝玉老师的这篇博客

四个秘籍：使用搜索引擎、社交媒体、Sora.com 平台以及反向分析法。

这些方法帮助用户掌握提示词使用的技巧，提高敏感度和理解力，通过模仿与融合不同风格的提示词，创造出新颖的视觉效果。网页还强调了分享自己的成功案例的重要性，通过分享和交流，形成正向循环，共同探索更多可能性。

后记（更多资源推荐） ​

欢迎在评论区自荐或推荐GPT-4o绘图资源

• 2025-04-14：开始有朋友收集此类提示词并整理为github仓库了，非常推荐看看：Awesome GPT-4o Images
• 2025-04-16：长贴演示GPT-4o绘图风格及场景
• 2025-04-16：有朋友整理了飞书多维表格，以及开源成了导航站

参考资料 ​

部分引用直接在文章内部引用，其他部分参考如下

• ChatGPT DeepRearch
• Grok DeeperSearch