我做产品出身，后来越来越多地把想法自己写出来、接上、部署好，再看它在真实使用里哪里会断。
比起先列技术栈，我更关心一个问题：这件事是不是真的值得做。值得做，再把它拆小，尽快做出能验证的版本。
- AI 工具产品化 · 工具要能进入真实工作流，而不是只在 demo 里好看
- Agent 系统 · 任务怎么拆、上下文怎么传、失败之后怎么恢复
- Memory System · 什么值得记、怎么检索、什么时候应该更新或忘掉
- 证据优先的 AI 阅读 · 读不到不补，没核验不写，把材料边界说清楚
- 全栈落地 · 从产品判断到前后端实现、接入、部署和日常维护
- 中文 AI 体验 · 让 AI 输出更贴近中文语境，少一点模板腔和翻译腔
| 维度 | 具体 |
|---|---|
| Languages |       |
| AI & LLM |       |
| Infra & Ops |        |
这些项目都围绕同一件事：把 AI 的能力收束成真实场景里可复用、可检查、能长期维护的工作流。
|
shuorenhua · 中文优先的 AI 输出修正工具（rewrite skill） 它处理的是一个很日常的问题：AI 写出来的内容经常语法没错，但不像真实的人在那个场景里会说的话。
|
| 解决什么问题 | 把 AI 生成内容里的模板腔、表演感和翻译腔压下去 |
| 方法独特在哪 | 先保护事实、术语、代码和引用，再处理风格 |
| 为什么代表我的做事方式 | 从真实使用里的不适感开始，把模糊感受拆成可以执行、评测和迭代的规则 |
|
paper-reading-zh · 中文论文精读的证据规则包 它解决的是 AI 读论文时最容易滑过去的问题：读不到的地方不硬补，没核验的外部事实不装作已经确认，多篇论文比较前先对齐口径。
|
| 解决什么问题 | 让 AI 论文阅读少一点顺滑猜测，多一点材料边界和证据锚点 |
| 方法独特在哪 | venue、年份、代码链接、实验数字和跨论文比较都先看是否可核验 |
| 为什么代表我的做事方式 | 把“别编”这种抽象要求拆成 Agent Skill 和 Web Prompt Kit 都能执行的规则 |
Agent 协作与记忆
长任务里的上下文组织、记忆检索、状态延续，以及多轮协作时的信息损耗。
AI 工具的评测与发布
把经验从“感觉好一点”推进到可以复查的样本、边界、版本说明和失败案例。还在验证的东西先留在日常使用里打磨，等边界和失败场景都讲得清楚，再整理成公开项目或文档。
- 先判断问题值不值得做，再决定怎么做
- 先做最小可用版本，再扩展复杂度
- 先保住事实和语境，再处理风格和体验
- 交付之后继续看部署、回滚、维护和长期稳定性
把模糊想法变成清晰方案，再把清晰方案做成能交付、能运行的东西。
Product sense decides what to build. Engineering decides whether it can actually ship.
