">
← 返回项目列表

04 · 个人开源项目 · 微信小程序原生

AI 创作助手小程序

面向小说与剧本创作者的写作工具链。4 个职责单一的 Agent,各自带独立的 System Prompt 与温度参数——用户选功能,而不是调参数。

我的工作 独立开发
技术栈 微信小程序原生(WXML / WXSS / JavaScript)· 腾讯混元大模型 API

概览

写作者会遇到四类不同的卡点:没灵感、剧情写不下去、文风不稳定、语句不流畅。它们对模型的要求是矛盾的——前两个要发散,后两个要严谨,用同一套参数很难同时满足。

项目把它们拆成 4 个独立 Agent,每个只做一件事,各自配不同的 System Prompt 和温度。用微信小程序原生实现,微信内搜索即可使用,不需要下载 App。

Agent 工作流

用户输入 主题 / 剧情 / 参考文本 / 草稿 灵感生成 输入:主题 / 关键词 输出:3–5 个角度 temperature 0.9 剧情续写 输入:已有剧情 输出:合理走向 temperature 0.7 风格仿写 输入:参考文本 输出:模仿文风 temperature 0.6 语法修饰 输入:草稿 输出:流畅优化 temperature 0.3 腾讯混元大模型 API 预设 System Prompt + 温度参数 微信小程序 WXML / WXSS / JavaScript 原生开发 无需下载 · 微信内搜索即用 发散 合理 模仿 严谨
4 个 Agent 并列而不是串联,用户可以任选一个单独使用。温度从发散的 0.9 一路收紧到严谨的 0.3,这个梯度就是这套工具的设计主线。

问题

  1. 市面上的 AI 写作工具两头不讨好

    要么只有"一键生成全文"——结果不可控,写出来的东西没法用;要么塞进几十个功能——学习成本高,用户找不到自己要的那一个。

  2. Web 端在手机码字场景里切换成本太高

    创作者主要在手机上写。用 Web 工具要开浏览器、登录、切标签页,写完还得复制回去,链路太长。

  3. 不同任务需要不同的模型参数,手动切换很麻烦

    灵感生成要发散、语法修饰要严谨,同一套参数无法兼顾。让用户自己理解并调整 temperature 是不现实的。

方案

  1. 014 个职责单一的 Agent

    灵感生成(发散,产出 3–5 个角度)、剧情续写(给定前文,生成合理走向)、风格仿写(模仿参考文本的文风)、语法修饰(优化流畅度,不改变原意)。每个只做一件事,用户可以按需组合。

    为什么拆开:一个全能入口需要用户把需求描述清楚("帮我生成灵感,然后续写剧情,再润色语法"),描述越复杂,模型理解错的概率越高。拆开之后每个入口的输入输出都很短,出错面小得多。

  2. 02微信小程序原生开发

    不依赖框架,直接用 WXML / WXSS / JavaScript。无需下载 App,微信内搜索即可使用。创作者在微信里长按文字 → 分享到小程序 → 选功能 → 拿结果,全程不离开微信生态。

    为什么不上框架:小程序环境不支持 npm 包和现代前端框架,原生是唯一选择。约束反而带来了好处——没有构建链路,包体小、启动快。

  3. 03预设 Prompt + 温度参数

    每个 Agent 配固定的 System Prompt 和温度:灵感生成 0.9(发散),剧情续写 0.7,风格仿写 0.6,语法修饰 0.3(严谨)。用户看到的只是四个功能按钮,不需要理解 temperature 是什么。

    为什么把参数藏起来:参数暴露给用户等于把调参成本转嫁出去,而大多数人不会调。把"这个任务需要多大发散度"这个判断留在设计阶段一次性做对,比提供一堆滑块有用。

关键决策

为什么做 4 个独立 Agent,而不是一个全能入口?

一个全能入口需要用户用自然语言描述复杂多步需求("帮我生成灵感,然后续写剧情,再润色语法"),描述越复杂,模型理解错的概率越高。拆开之后每个入口的输入输出都很短:灵感生成只要主题,语法修饰只要草稿,出错面小得多。代价是多了选择步骤,但用户选按钮比用文字描述需求要快。

为什么选微信小程序,而不是 Web?

创作者主要在手机上写,在微信、备忘录、文档 App 里码字。用 Web 工具要开浏览器、登录、切标签页,写完还得复制回去,链路太长。小程序可以长按文字 → 分享到小程序 → 选功能 → 拿结果,全程不离开微信生态。代价是开发受限——小程序环境不支持 npm 包和现代前端框架,只能用原生 WXML / WXSS / JavaScript。约束反而带来好处:没有构建链路,包体小、启动快。

为什么把温度参数藏起来,而不是让用户调?

参数暴露给用户等于把调参成本转嫁出去,而大多数人不知道 temperature 是什么、0.3 和 0.9 的区别在哪、自己的任务应该用多大。与其提供一堆滑块让人困惑,不如在设计阶段一次性做对:"这个任务需要多大发散度?"这个判断应该在产品设计时决定,而不是在使用时让用户猜。灵感生成 0.9(发散)、剧情续写 0.7、风格仿写 0.6、语法修饰 0.3(严谨)——用户看到的只是"我要发散还是要严谨",这个选择是直观的。

为什么做成并列而不是串联?

串联流程("灵感 → 剧情 → 润色"自动执行)看起来完整,但有两个问题:① 中间某步出错整条链路就断了;② 用户失去控制权,只能接受最终结果。并列方式让用户自己决定组合顺序、跳过哪一步、把哪一步的结果拿去手动修改再继续。灵活性更高,失败面更小。

结果

4

独立 Agent

各自独立的 Prompt 与温度,可单独或组合使用

0.3–0.9

温度区间

按任务发散度梯度设定,对用户隐藏

0

npm 依赖

原生 WXML / WXSS / JS,无构建链路

已知边界

  • 01
    不支持长文本。单次输入上限约 2000 字,长章节需要自己切段处理。
  • 02
    不支持多轮对话。每次请求彼此独立,Agent 之间不共享会话上下文,想要迭代得手动把上一轮结果粘回来。
  • 03
    历史记录只在本机。没有云端同步,换设备或清缓存后历史就丢了。