参赛项目名称
妙笔（Writer Assistant）· 人人可用的 AI 写作工作台
妙笔是一个 AI 写作工作台。它把 AI 和 Skill 的能力融入写作工作流，真正用 AI 帮用户提升写作产出率。
在流程中，AI 找新闻、提供选题、生成初稿和内容诊断；用户始终负责方向、事实、判断和最终表达。
团队 / 作者
个人参赛
GitHub：@hotcoffeeshake
产品设计、前后端开发、AI Pipeline、Skill 编排与阿里云部署由个人完成。
30 秒看懂妙笔
普通人用 AI 写作往往停留在说一句提示词，最终只有一篇通顺但缺少个人声音的机器稿。
妙笔先给用户提供想看的新闻和爆款内容，再从中提炼标题公式：
新闻和爆款浏览
↓
AI 提取爆款公式，并生成带证据的选题候选
↓
用户判断这个选题值不值得写
↓
选择快速成稿，或通过深度访谈补齐经历、立场和受众
↓
生成一份可继续编辑的底稿
↓
DBS / 读者视角诊断开头、场景、事实和表达问题
↓
用户逐条决定是否修改
↓
审核定稿，生成适配平台比例的 AI 封面
↓
回填发布链接，复盘前后差异并沉淀写作偏好
演示视频
▶ 点击播放演示视频（约 1 分 37 秒，8.1 MB）
为什么我要做它？
很多做内容获客的朋友跟我讲，一篇内容从想选题到写完要花两三个小时，甚至更久。
他们知道 AI 能帮上忙，但试过之后又觉得写出来的东西机械、死板、缺乏深度，改起来比自己写还累。
问题在于，AI 不知道你是谁、你的读者是谁，也不知道你的写作意图。想让 AI 写出符合我们想法的内容，需要的是 AI、科学工作流和专用 Skill 的组合。
也就是给 AI 套上缰绳，让作者骑着这匹骏马，文思如涌。
妙笔想解决两个问题：
- 流程碎片化：把素材、选题、成稿、修改、封面、发布和复盘放进同一条工作流；
- 表达同质化：让 AI 做加工和辅助，把事实、立场与最终决定留给用户。
我的原则是：把 AI 做成更高级的笔，帮助用户写作，但不代替用户表达。
百炼在这个项目里做了什么？
百炼不仅参与开发，也是妙笔线上写作和封面生成链路的一部分。
Next.js 写作工作台
↓
七阶段状态与文章上下文
↓
Skill 编排层
↓
阿里云百炼模型推理
↓
诊断 / 成稿 / 封面结果
↓
用户确认、版本保存与发布归档
为了让更多评审和真实用户能直接用上妙笔，项目新增了基于邮箱验证码的登录方式。注册与登录验证码通过阿里云能力下发到用户邮箱，用户凭「邮箱 + 验证码」即可完成认证，无需第三方账号就能创建独立账号。
每一条写作数据在落库前先绑定当前账号，不同用户之间互不可见，登录态由 NextAuth 统一管理。这让妙笔从「单机演示」变成了「多用户可用的真实产品」。
同时建议把 技术实现 里的：
鉴权：NextAuth
改为：鉴权：NextAuth + 阿里云邮箱验证码登录
文本能力
项目通过 DashScope OpenAI Compatible API 调用百炼上的 DeepSeek-V3，用于：
- 素材结构化；
- 生成带依据的选题候选；
- 快速成稿；
- 深度访谈与访谈后成稿；
- DBS 标题、内容和开头诊断；
- 目标读者测试；
- 发布复盘与偏好提取。
AI 网关统一处理用户级调用、超时、限流、积分预检和真实 Token 用量；调用失败时不扣除用户积分。
自动配封面
项目通过阿里云百炼 / DashScope 调用通义万相 wanx2.1-t2i-turbo，结合 Skill 市场的 illustration-generator，根据文章内容、标题和发布平台生成不同尺寸、不同风格的封面配图，把找图、裁比例、适配平台这些机械的收尾工作交给 AI，用户只需决定审美与比例。
| 平台 | 比例 |
|---|
| 微信公众号 | 2.35:1 |
| 小红书 | 3:4 |
| Twitter / 飞书 | 16:9 |
| Web | 1.91:1 |
支持纽约客、极简、水彩等风格。用户决定平台、比例和审美方向，AI 负责完成生成与适配。
Skill 如何进入真实写作流程
妙笔没有把 Skill 做成与文章分离的工具箱，而是把不同方法放进最需要它们的阶段：
| Skill / 方法 | 所在阶段 | 解决的问题 |
|---|
| DBS 标题公式 | 选题 / 成稿 | 生成标题候选并提示风险 |
| DBS 内容诊断 | 初改稿 / 审核 | 找出选题、结构、场景和承诺问题 |
| DBS 开头优化 | 初改稿 | 判断开头是否拖沓、抽象、缺少冲突 |
| doc-coauthoring 读者测试（百炼 Skill 市场） | 初改稿 / 审核 | 模拟不同读者寻找困惑、不信和跳过的位置 |
| doc-coauthoring（百炼 Skill 市场） | 深度访谈 | 在成稿前补齐经历、立场与受众上下文 |
| AI Vibe Writing（百炼 Skill 市场） | 成稿 / 复盘 | 提取并逐步保持用户的写作偏好 |
| illustration-generator（百炼 Skill 市场） | 发布 | 根据文章和平台生成封面 |
| alibabacloud-ecs-code-deploy（百炼 Skill 市场） | 部署 | 把应用部署到阿里云 ECS |
它们共同服务于同一条文章生命周期，而不是让用户每次重新复制正文、重新解释上下文。
技术实现
- 前端 / 全栈框架：Next.js 15 + React 19 + TypeScript + Tailwind CSS
- 状态管理：Zustand
- 数据库：PostgreSQL + Prisma
- 数据校验：Zod
- 鉴权：NextAuth
- 文本模型：百炼 DashScope 兼容接口 + DeepSeek-V3
- 图像模型：通义万相
wanx2.1-t2i-turbo - 部署：阿里云 ECS
核心数据包括素材、选题、文章、修改版本、发布记录、Skill 运行记录和用户写作偏好。不同用户的数据按账号隔离，文章修改与阶段推进均落库保存。
效果展示
① 素材浏览：一个入口查询全网热点，激发写作灵感
AI 会抓取全网热点信源，用户也可以导入自己的素材，用新闻和爆款内容激发写作灵感。
② 选题判断：AI 给候选，用户拍板
妙笔可以从全网抓取到的爆款内容里提炼开头写法和标题公式，生成一批带证据的选题，但决定要不要写的还是人。
③ 写作成稿：快速模式与深度访谈
方向明确时快速成稿；上下文不足时先进行多轮访谈，把用户自己的经历、立场和语气带入文章。
④ 初改稿：诊断与 Diff
网上有许多创作者分享自己的写作方法。妙笔精选了一套用于诊断内容与开头的 Skill，写完后可以从读者和 DBS 视角，指出文章在表达效率、认知落差、场景和可信度等方面的不足。
⑤ 审核：发布前最后确认
通过审核清单和诊断摘要完成最终确认，避免文章在事实、结构和表达上带着明显问题进入发布阶段。
⑥ 发布：正文归档与 AI 封面
在发布环节，妙笔还能根据发布平台生成封面配图。找图、裁比例、适配各平台，是最机械、最磨人的收尾工作。用户定下审美和平台，剩下的交给 AI。
⑦ 复盘：让每篇文章成为下一篇的起点
系统对比成稿前后的变化，提取本次创作中得到确认的偏好，沉淀为长期 Writing Profile。
当前部署状态与项目链接
推荐评审体验路径
注册 / 登录
→ 素材浏览
→ 从素材生成选题
→ 采用一个选题
→ 选择快速成稿或深度访谈
→ 查看 DBS 诊断与 Diff
→ 推进到审核
→ 生成平台封面
→ 回填发布链接
→ 查看复盘结果
踩坑记录
1. UI 不应在生产环境里反复试错
早期直接在生产页面上持续调整 UI，导致部署频繁、反馈周期变长。后来改为先在设计画布中确认结构和交互，再集中实现与部署。
**教训：**生产部署应该验证已经形成的设计决策，而不是代替设计过程。
2. 操作生产库前，先确认真实运行进程使用的数据源
生产数据库连接只存在于 ECS 上的 Next.js 进程环境变量中，项目目录没有 .env。最终通过阿里云 Cloud Assistant 在实例内读取真实进程环境，并复用实例内的 Prisma Client 执行操作。
**教训：**不能根据本地配置猜测生产数据源；任何生产数据操作都必须先确认目标连接。
3. 安全守卫也可能破坏正常开发流程
本地开发服务启动后退出，根因不是 Next.js，而是 safe-delete 守卫拦截了 .next 缓存清理。最终把开发缓存目录迁移到 /tmp，将构建缓存与项目资产分离。
**教训：**安全策略必须区分用户资产和可再生缓存，否则保护机制本身会成为故障源。
4. Skill Manifest 是外部契约，不能假设结构永远一致
工作台曾因前端读取顶层 inputSchema，而真实数据位于 manifest.inputSchema，导致页面白屏。最终增加错误边界、Manifest 适配层和防御性判空。
**教训：**外部 Skill 接入必须经过统一适配和运行时校验，不能让原始结构直接进入 UI。
5. 发布成功不等于生命周期已经结束
早期用户填写发布链接后，复盘页面仍然为空。根因是发布记录已经更新，但文章没有同步推进到复盘阶段。修复后，确认发布会同步完成状态流转，并保留对历史数据的兼容读取。
**教训：**工作流产品不能只验证单个接口成功，还必须验证业务对象是否真正进入下一个生命周期阶段。
我刻意没有让 AI 做的事
- 不让 AI 替用户决定选题；
- 不把未经确认的推断写成用户经历；
- 不用“一键优化”直接覆盖原文；
- 不跳过用户确认自动发布；
- 不把一次生成结果当成不可修改的最终答案；
- 不让复盘得到的偏好在用户不可见的情况下替用户定义风格。
妙笔希望先证明一件事：
当 AI 被放在正确的位置，效率和个人表达并不冲突。
参赛项目名称
妙笔（Writer Assistant）· 人人可用的 AI 写作工作台
妙笔是一个 AI 写作工作台。它把 AI 和 Skill 的能力融入写作工作流，真正用 AI 帮用户提升写作产出率。
在流程中，AI 找新闻、提供选题、生成初稿和内容诊断；用户始终负责方向、事实、判断和最终表达。
团队 / 作者
个人参赛
GitHub：@hotcoffeeshake
产品设计、前后端开发、AI Pipeline、Skill 编排与阿里云部署由个人完成。
30 秒看懂妙笔
普通人用 AI 写作往往停留在说一句提示词，最终只有一篇通顺但缺少个人声音的机器稿。
妙笔先给用户提供想看的新闻和爆款内容，再从中提炼标题公式：
演示视频
▶ 点击播放演示视频（约 1 分 37 秒，8.1 MB）
为什么我要做它？
很多做内容获客的朋友跟我讲，一篇内容从想选题到写完要花两三个小时，甚至更久。
他们知道 AI 能帮上忙，但试过之后又觉得写出来的东西机械、死板、缺乏深度，改起来比自己写还累。
问题在于，AI 不知道你是谁、你的读者是谁，也不知道你的写作意图。想让 AI 写出符合我们想法的内容，需要的是 AI、科学工作流和专用 Skill 的组合。
也就是给 AI 套上缰绳，让作者骑着这匹骏马，文思如涌。
妙笔想解决两个问题：
我的原则是：把 AI 做成更高级的笔，帮助用户写作，但不代替用户表达。
百炼在这个项目里做了什么？
百炼不仅参与开发，也是妙笔线上写作和封面生成链路的一部分。
为了让更多评审和真实用户能直接用上妙笔，项目新增了基于邮箱验证码的登录方式。注册与登录验证码通过阿里云能力下发到用户邮箱，用户凭「邮箱 + 验证码」即可完成认证，无需第三方账号就能创建独立账号。
每一条写作数据在落库前先绑定当前账号，不同用户之间互不可见，登录态由 NextAuth 统一管理。这让妙笔从「单机演示」变成了「多用户可用的真实产品」。
同时建议把 技术实现 里的：
鉴权：NextAuth
改为：鉴权：NextAuth + 阿里云邮箱验证码登录
文本能力
项目通过 DashScope OpenAI Compatible API 调用百炼上的 DeepSeek-V3，用于：
AI 网关统一处理用户级调用、超时、限流、积分预检和真实 Token 用量；调用失败时不扣除用户积分。
自动配封面
项目通过阿里云百炼 / DashScope 调用通义万相
wanx2.1-t2i-turbo，结合 Skill 市场的illustration-generator，根据文章内容、标题和发布平台生成不同尺寸、不同风格的封面配图，把找图、裁比例、适配平台这些机械的收尾工作交给 AI，用户只需决定审美与比例。支持纽约客、极简、水彩等风格。用户决定平台、比例和审美方向，AI 负责完成生成与适配。
Skill 如何进入真实写作流程
妙笔没有把 Skill 做成与文章分离的工具箱，而是把不同方法放进最需要它们的阶段：
它们共同服务于同一条文章生命周期，而不是让用户每次重新复制正文、重新解释上下文。
技术实现
wanx2.1-t2i-turbo核心数据包括素材、选题、文章、修改版本、发布记录、Skill 运行记录和用户写作偏好。不同用户的数据按账号隔离，文章修改与阶段推进均落库保存。
效果展示
① 素材浏览：一个入口查询全网热点，激发写作灵感
AI 会抓取全网热点信源，用户也可以导入自己的素材，用新闻和爆款内容激发写作灵感。
② 选题判断：AI 给候选，用户拍板
妙笔可以从全网抓取到的爆款内容里提炼开头写法和标题公式，生成一批带证据的选题，但决定要不要写的还是人。
③ 写作成稿：快速模式与深度访谈
方向明确时快速成稿；上下文不足时先进行多轮访谈，把用户自己的经历、立场和语气带入文章。
④ 初改稿：诊断与 Diff
网上有许多创作者分享自己的写作方法。妙笔精选了一套用于诊断内容与开头的 Skill，写完后可以从读者和 DBS 视角，指出文章在表达效率、认知落差、场景和可信度等方面的不足。
⑤ 审核：发布前最后确认
通过审核清单和诊断摘要完成最终确认，避免文章在事实、结构和表达上带着明显问题进入发布阶段。
⑥ 发布：正文归档与 AI 封面
在发布环节，妙笔还能根据发布平台生成封面配图。找图、裁比例、适配各平台，是最机械、最磨人的收尾工作。用户定下审美和平台，剩下的交给 AI。
⑦ 复盘：让每篇文章成为下一篇的起点
系统对比成稿前后的变化，提取本次创作中得到确认的偏好，沉淀为长期 Writing Profile。
当前部署状态与项目链接
推荐评审体验路径
踩坑记录
1. UI 不应在生产环境里反复试错
早期直接在生产页面上持续调整 UI，导致部署频繁、反馈周期变长。后来改为先在设计画布中确认结构和交互，再集中实现与部署。
**教训：**生产部署应该验证已经形成的设计决策，而不是代替设计过程。
2. 操作生产库前，先确认真实运行进程使用的数据源
生产数据库连接只存在于 ECS 上的 Next.js 进程环境变量中，项目目录没有
.env。最终通过阿里云 Cloud Assistant 在实例内读取真实进程环境，并复用实例内的 Prisma Client 执行操作。**教训：**不能根据本地配置猜测生产数据源；任何生产数据操作都必须先确认目标连接。
3. 安全守卫也可能破坏正常开发流程
本地开发服务启动后退出，根因不是 Next.js，而是 safe-delete 守卫拦截了
.next缓存清理。最终把开发缓存目录迁移到/tmp，将构建缓存与项目资产分离。**教训：**安全策略必须区分用户资产和可再生缓存，否则保护机制本身会成为故障源。
4. Skill Manifest 是外部契约，不能假设结构永远一致
工作台曾因前端读取顶层
inputSchema，而真实数据位于manifest.inputSchema，导致页面白屏。最终增加错误边界、Manifest 适配层和防御性判空。**教训：**外部 Skill 接入必须经过统一适配和运行时校验，不能让原始结构直接进入 UI。
5. 发布成功不等于生命周期已经结束
早期用户填写发布链接后，复盘页面仍然为空。根因是发布记录已经更新，但文章没有同步推进到复盘阶段。修复后，确认发布会同步完成状态流转，并保留对历史数据的兼容读取。
**教训：**工作流产品不能只验证单个接口成功，还必须验证业务对象是否真正进入下一个生命周期阶段。
我刻意没有让 AI 做的事
妙笔希望先证明一件事：