北京
一个按钮被删掉了，整个工具的设计逻辑跟着变了。这不是产品迭代的常规故事，而是一个开发者对自己默认设置的反思。
这个写作工作流工具是一个终端里的写作工具，作者用它来写技术文章。它把写作周围的步骤融进一个终端工作流：调研 → 找角度 → 编辑简报 → 确认大纲 → 写作 → 审阅 → 发布。步骤之间的产物都存在纯 Markdown 文件里，只有两个地方需要人做决定——确认简报，以及接受或拒绝审阅建议。
问题出在确认简报之后。原本那里有一个按钮，写着「生成草稿」。按下它，大纲就会变成一篇看起来像成品文章的东西。作者把这个按钮删了，理由值得细看。
默认值在替工具表态
确认简报，本来的含义是「我同意这个方向」。但那个按钮把它变成了「现在把所有正文都生成出来」。一次按键，从大纲直接跳到成品模样。
作者担心的是：如果别的写作者来用这个工具，这个按钮会不会鼓励完全由 AI 写成的文章？技术文章之所以有用，是因为它带着只有作者才有的东西——真实的 bug、比预想更难的取舍、让人意外的发现。一个从大纲出发的模型没有这些，它只会用看似合理、自信、可互换的文字把空缺填满。
作者没有说别人不该用 AI 起草，那是每个写作者自己的选择。他的决定更窄：他不想造一个把推荐路径指向那里的工具。默认值会告诉人们工具期待他们做什么，所以他干脆把草稿生成整个删掉，而不是藏进某个设置项里。
现在确认简报之后，下一步动作是打开 working.md，自己写。
审阅需要真实的文字
审阅功能需要真正的正文。如果 working.md 里只有一个标题，「审阅我的草稿」就可能悄悄变成「替我写一篇」。这个工具拒绝审阅只有标题的文件。一旦有了文字，它会看结构、语气，以及那些听起来比证据支持的更确定的说法，所有结果都以建议的形式返回，你可以接受、编辑或忽略。
针对某个卡住的段落，它会先问你想做什么，选项包括：我自己写这一段、给我一些要点提示、帮我开个头、先跳过。模型只在你主动要求时才被调用，结果是一份建议，除非你接受，否则永远不会动到 working.md。
建议会过期。如果它审阅了你的文章，之后你重写了三段，再接受旧建议就等于把它套用在一个已经不存在的版本上。它在生成修订时会记录源文章的 SHA-256 摘要，接受时再核对一次：来源与当前文章不一致，就判定为过期，拒绝应用。
空缺留在明面上
当模型没有真实例子时，它会编一个。所以这个工具把属于作者的空缺留在那里不解决，而不是糊过去。文件里会出现这样的占位标记，提醒你补上真实的调试问题。
对说法的处理也一样。它会标出值得核实的陈述，并说明什么样的证据会有帮助，但它不会宣布这些陈述为真。说法报告和修订分开存放，不确定性无法被接受进已验证的正文，它变成一份待调研清单。
这个工具比那种一分钟给你一篇草稿的工具要慢，这是有意为之。它仍在开发中，作者也承认有些选择可能需要调整。但他想获得帮助的部分是调研、结构和核查，这些都不需要工具替他写文章。
关于隐私：它是本地优先的，项目存在你自己的机器上，随时可以检查。但当你请求模型帮助时，相关上下文会发送到你配置的服务商。它也没有自动发布这一步。
作者原本以为这个教训是关于 AI 的，结果发现是关于默认值的。一个被推荐的按钮，塑造了文件布局、审阅逻辑，以及他如何看待这个工具里谁拥有什么。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
