在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝
公开材料尚未说明用户目前如何完成这项工作、它实际替代了什么。
它试图减少完成这项任务时的摩擦;公开用户材料尚未说明不解决的具体代价、发生频率或后果。
AI 应用的生意判断
在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝
01
从用户的一天开始 · 公开事实 + 工作流推理 · 2026-08-28
在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝
公开材料尚未说明用户目前如何完成这项工作、它实际替代了什么。
它试图减少完成这项任务时的摩擦;公开用户材料尚未说明不解决的具体代价、发生频率或后果。
趋势是给 AI 的反馈要从整篇重写,退回「追加建议」。不要做又一个写作助手,先切方案、合同、手册这种必须看清改了哪句的审查。方法免费,还看不清独立产品。
它承诺用更直接的方式完成这项任务:在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝;具体采用动机与持续使用情况尚未核验。
① 有没有编辑器或写作工具把"追加式建议"交互吸收掉——验证了这个方法是不是公共品; ② 仓库的 star/issue 有没有动静——bookmarklet 类项目最常见的结局是作者自用; ③ 作者有没有把规范发展成跨工具标准——"注释即脚注"如果只在一个 bookmarklet 里就没意义
继续观察。它承诺用更直接的方式完成这项任务:在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝;具体采用动机与持续使用情况尚未核验。
任何 AI 内容工具的审查环节,都值得抄"追加式建议 + 可寻址批注"这对设计—— 它同时给了你权限边界和可审理性。具体到实现,把批注编码进脚注 id 让格式保持兼容, 是低成本高回报的一笔。
无。 免费 bookmarklet,开源(github.com/martin-lysk/markleft),无定价页。 ① 有没有编辑器或写作工具把"追加式建议"交互吸收掉——验证了这个方法是不是公共品; ② 仓库的 star/issue 有没有动静——bookmarklet 类项目最常见的结局是作者自用; ③ 作者有没有把规范发展成跨工具标准——"注释即脚注"如果只在一个 bookmarklet 里就没意义
在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝
它承诺用更直接的方式完成这项任务:在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝;具体采用动机与持续使用情况尚未核验。
公开补证:查找官方定价、客户案例或部署文档,确认谁付钱、不使用的代价及可确定交付的结果。
产品主张帮助用户完成:“在文稿上直接批注,AI 只追加修改建议、原文不动,你逐条点头或拒绝”。具体痛点强度与不采用代价尚未由用户证据核验。
已有采用或关注仍应记录,但不能替代痛点证据;未见持续使用、部署、复购或公开用户反馈,不能据此判断是否形成共识。
付费主体、定价与单位经济尚未核验;这是商业证据缺口,不反推问题不存在。
交付能否稳定发生、以及人工与安全边界,尚缺可复现的公开证据。
02
市场对照
尚未完成中英文市场对照。待覆盖范围和可核验证据补齐后再给出结论。
03
先给出判断与下一步,再保留完整证据和反例。
给 Markdown 装一个"建议模式":你在文档上直接批注(文字、代码、表格、图表、SVG 都可以), AI 只追加建议而不是整篇重写,你逐个确认。
Martin R. Lysk(HN: mlysk),个人开发者。一个 Chrome bookmarklet + 一个标注规范(spec)+ 一篇 11 分钟的博客文章(2026-08-09),代码在 github.com/martin-lysk/markleft。
判断:这是个"方法论先于产品"的项目——文章先把当前流程为什么荒谬讲透,再给工具。这个顺序 本身值得注意:它默认读者是"想改进 AI 写作迭代流程"的人,而不是"想装个插件"的人。
markleft:block id=... 的 HTML 注释,结构性改动也能被寻址它明确不做:不改 Markdown 文件格式本身,不做云服务,不走"AI 改写全文"的默认路径。
现在和 AI 迭代一篇长文档的默认流程:你在对话里用一段文字描述哪里不满意 → AI 重写整篇 → 你在新旧两版之间做"找不同" → 还要回忆你原话里哪句对应了哪处改动。作者在文章里把这件事 类比成"给同事寄一篇五页文档,回我一封散文式的批评,然后发我一版完全重写的版本,再让我 自己对比两版判断你听没听懂"——这套流程文档协作在二十年前就用批注和修订解决了。
markleft 替代的是"散文式反馈 + 整篇重写 + 人肉 diff"这条荒谬链路,把它变成"原位批注 + 追加式建议 + 定位到批注的 diff"。这个思路可以迁移到任何 AI 生成文档的审查场景, 不只是 Markdown。
无。 免费 bookmarklet,开源(github.com/martin-lysk/markleft),无定价页。
判断:这是纯技术/方法论文案,没有商业意图的痕迹。它的价值在方法,不在产品形态。
| 维度 | 结论 |
|---|---|
| 创始人-产品匹配度 | 作者显然是重度用 AI 写文档的人,痛点是亲历的;方法论写得很透 |
| 产品洞察力 | "追加式建议"对抗"整篇重写"是当前 AI 写作工具最大的未解决问题之一,这个切入点选得准 |
| 技术实现质量 | 注释即脚注的规范很聪明,兼容普通 Markdown 渲染器;但 bookmarklet 形态限制了传播 |
| 市场时机 | AI 写文档正进入"产出量大于审核能力"阶段,审查工具的需求在起来,但买单方还没清晰 |
这是"把文档协作二十年前就解决过的问题,重新翻译给 AI 时代"的标准案例。
批注和修订在 Word/Google Docs 里解决了"人和人怎么改一份文档",但 AI 来了之后大家集体退回 了"描述 + 重写 + 人肉 diff"的原始流程。markleft 做的不是发明新交互,是把旧交互的约束翻译成 AI 能消费的格式——追加式、可寻址、可接受可拒绝。
可迁移的规律:给 AI 工具的反馈通道,优先考虑"追加"而不是"重写"。 追加是权限边界,也是 可审理性边界:AI 可以提出任何建议,但不能动你的原文。这个约束同时解决了两个问题—— 防越权,和让人能快速确认"改了什么、对应哪个意见"。
它的天花板也很诚实:bookmarklet 是个人工具形态,8 points 说明没什么人看到。这个方法的 真正归宿可能是被编辑器、Claude 的 Artifacts 或文档工具吸收,而不是自己长成产品。
① 有没有编辑器或写作工具把"追加式建议"交互吸收掉——验证了这个方法是不是公共品 ② 仓库的 star/issue 有没有动静——bookmarklet 类项目最常见的结局是作者自用 ③ 作者有没有把规范发展成跨工具标准——"注释即脚注"如果只在一个 bookmarklet 里就没意义
产品逻辑:任何 AI 内容工具的审查环节,都值得抄"追加式建议 + 可寻址批注"这对设计—— 它同时给了你权限边界和可审理性。具体到实现,把批注编码进脚注 id 让格式保持兼容, 是低成本高回报的一笔。
定价结构:无。免费 + 开源。
方法值钱,产品还没长出来。 "追加式建议"是 AI 文档协作里少数能同时解决权限和可审核问题 的设计,8 points 不影响它的方法价值。但 bookmarklet 形态和零商业化迹象决定了它大概率停在 个人工具层面。记下这个交互模式,等它在别的产品里被吸收。
05
产品官网缺失或当前链接只是线索时,从这些检索入口继续核验。