<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>


<command-name>/clear</command-name>
            <command-message>clear</command-message>
            <command-args></command-args>


<local-command-stdout></local-command-stdout>


<command-name>/exit</command-name>
            <command-message>exit</command-message>
            <command-args></command-args>


<local-command-stdout>Catch you later!</local-command-stdout>


No response requested.


<command-name>/model</command-name>
            <command-message>model</command-message>
            <command-args></command-args>


<local-command-stdout>Set model to Opus 4.6 (1M context)</local-command-stdout>


下面这段是由obsidian bot生成的文字，你再看看哪里有ai味，并告诉我应该怎么修改:让 AI 助手直接在主力电脑上跑，这事听起来很酷，实际在大规模落地时是个巨大的坑。第一个绕不开的坎是权限与安全。想让 Agent 真正干活，整理文档、跑代码、查本地数据库，必须开放文件读写权限。现在的模型远没到完全可信的程度。一旦理解指令产生幻觉，或者执行 Python 脚本时逻辑跑偏，直接在主系统里执行删除或覆盖操作，破坏性是灾难级的。没必要为了用个助手，天天提心吊胆盯着 C 盘。专门准备隔离的执行环境是标配。目前主流方案有三种：本地虚拟机、闲置备用电脑、云服务器。本地虚拟机能做到物理隔离，但性能损耗和配置复杂度非常折磨人。分出几十 GB 内存和大量 CPU 核心后，主力机会卡到带不动其他生产力工具。虚拟机文件传输逻辑笨拙，处理大文件还得在宿主机和虚拟机之间折腾共享文件夹。闲置电脑最大的问题是数据碎裂。工作流分散在两台机器上，同步状态像一场小型迁徙。这种物理硬件的横向扩展能力几乎为零，不可能为了跑三个不同的 Agent 去买三台电脑。长远来看，云服务器是 Agent 真正的归宿。云服务器本质上是 24 小时在线的数字化容器。它不依赖家里闪断的宽带，也不依赖主力机是否关机。出门在外通过手机或 iPad 随能接续远端任务。这种永远在线的特性是本地硬件无法提供的安全感。核心逻辑在于可迁移性和未来的 SaaS 化能力。在云上构建好完整、自动化的 AI 工作流，等于拥有了属于自己的微型 SaaS 服务。这意味着随时可以把能力打包、复制，甚至分享给团队。云上预置好了环境依赖，适配好了各种 Sandbox 协议，这比在本地重装一遍系统的成本低了不止一个量级。未来的云服务会产生一种新的形态：温和池架构。云计算厂商会预先创建好无数个部署好环境依赖的虚拟机，像水电一样储备。需要 AI 执行复杂任务时，路由层会毫秒级分配一个就绪环境。这种即刻满足感和阅后即焚的安全性，会让本地部署显得像工业时代手磨零件一样低效。代码应该是连接模糊意图与确定物理世界的桥梁。云服务器就是这座桥梁最坚固的地基。对于普通用户来说，现在的门槛确实存在。需要理解如何选 VPS，怎么做安全加固，甚至处理守护进程。但这种复杂度值得跨越。与其在主力机上和 AI 玩不安全的捉迷藏，不如早点把它的灵魂安置在云端。


The user wants me to review a piece of text generated by their Obsidian bot and identify where it has "AI tone" (AI味), then suggest how to fix it. Let me analyze the text carefully.

The text is about why AI assistants should run on cloud servers instead of local machines. Let me identify the AI-ish patterns:

1. **过度使用比喻和修辞** - AI loves metaphors:
   - "像一场小型迁徙" - forced metaphor
   - "像水电一样储备" - ok but a bit cliché
   - "像工业时代手磨零件一样低效" - overly dramatic comparison
   - "代码应该是连接模糊意图与确定物理世界的桥梁" - very AI-sounding philosophical statement
   - "把它的灵魂安置在云端" - dramatic/poetic ending
   - "云服务器就是这座桥梁最坚固的地基" - extended metaphor, very AI

2. **过度渲染/夸张**:
   - "破坏性是灾难级的" - overly dramatic
   - "天天提心吊胆盯着 C 盘" - exaggerated language that feels forced
   - "性能损耗和配置复杂度非常折磨人" - unnecessarily dramatic framing
   - "即刻满足感和阅后即焚的安全性" - relies too heavily on trendy terminology

3. **假装有情感/立场但实际空洞**:
   - "这种永远在线的特性是本地硬件无法提供的安全感" - uses vague emotional language without substance
   - "这种复杂度值得跨越" - reads like an inspirational slogan

4. **概念堆砌/大词**:
   - "温和池架构" (warm pool architecture) - real concept but applied loosely
   - "SaaS 化能力" - buzzword without clear meaning
   - "数字化容器" - unnecessary jargon that obscures the actual point

5. **结构上的 AI 味**:
   - 开头故意装作随意"这事听起来很酷"，然后立刻转向正式语气
   - 每段都遵循"首先...其次...最后"的机械结构
   - 结尾总要升华到哲学高度

6. **一些句子太满太圆**:
   - "等于拥有了属于自己的微型 SaaS 服务" - 表述过于完美
   - "这比在本地重装一遍系统的成本低了不止一个量级" - "不止一个量级"是典型的 AI 用语

现在我需要给出具体可行的建议，指出确切的措辞问题。


整体读下来，内容逻辑是通的，但 AI 味主要集中在这几类问题：

**1. 比喻堆砌过猛**

AI 特别爱用比喻来"升华"，一篇文章里塞太多就假了：

- "像一场小型迁徙" → 直接说"同步很麻烦"
- "像工业时代手磨零件一样低效" → 删掉，前面已经说清楚了
- "代码应该是连接模糊意图与确定物理世界的桥梁。云服务器就是这座桥梁最坚固的地基。" → 这两句是典型的 AI 升华体，整段删掉
- "把它的灵魂安置在云端" → 改成"把环境搬到云上"

**2. 用力过猛的形容词/副词**

- "破坏性是灾难级的" → "后果很严重"或者直接举个例子
- "非常折磨人" → "很烦"
- "笨拙" → "麻烦"
- "不止一个量级" → 这个词组 AI 用烂了，换成具体对比或者直接删

**3. 造概念 / 大词空转**

- "24 小时在线的数字化容器" → 就说"一台 24 小时开着的远程机器"
- "温和池架构" → 如果读者不是做云计算的，这个词没有信息量，要么展开解释，要么换成大白话"厂商预热好一堆虚拟机等着你用"
- "即刻满足感和阅后即焚的安全性" → 拆开说：启动快、用完销毁

**4. 结尾鸡汤化**

最后一段"这种复杂度值得跨越……不如早点把它的灵魂安置在云端"是典型的 AI 收尾——先承认困难，再来一句励志。建议改成实际的行动建议，比如推荐一个具体的入门路径或最小可行方案。

**5. 语气不统一**

开头"这事听起来很酷"走口语路线，中间突然切回书面语"核心逻辑在于可迁移性"，再到结尾又变抒情。选一个调性保持住——既然是个人博客，全程用口语就行。

**总结改法**：砍掉所有比喻只保留最多一个，大词换成具体描述，结尾给行动方案别给鸡汤，语气统一走口语。


那对于几个指导写作的md文档是否需要修改？还是说增加一个新的步骤


The user is asking about their writing guide markdown files - whether they need to modify existing ones or add a new step. This is related to their Obsidian bot's content generation pipeline. Let me look at the relevant files to understand the current writing guide structure.

Let me search for the guide/instruction MD files related to the Obsidian bot's writing process.


让我先看看当前的写作指导文件有哪些。


Agent

Prompt: Find all markdown files related to writing guides, prompts, or instructions for the Obsidian bot content generation. Look in directories like slack_bot/obsidian/, prompts/, guides/, or any other location that might contain writing style guides or article generation instructions. Search for files containing keywords like "写作", "style", "tone", "guide", "prompt", "template", "article", "生成", "deai", "去AI". Be thorough - check the entire project. Return the full paths and a brief summary of each file's content.

Find writing guide MD files


Find all markdown files related to writing guides, prompts, or instructions for the Obsidian bot content generation. Look in directories like slack_bot/obsidian/, prompts/, guides/, or any other location that might contain writing style guides or article generation instructions. Search for files containing keywords like "写作", "style", "tone", "guide", "prompt", "template", "article", "生成", "deai", "去AI". Be thorough - check the entire project. Return the full paths and a brief summary of each file's content.

Prompt: Find all markdown files related to writing guides, prompts, or instructions for the Obsidian bot content generation. Look in directories like slack_bot/obsidian/, prompts/, guides/, or any other location that might contain writing style guides or article generation instructions. Search for files containing keywords like "写作", "style", "tone", "guide", "prompt", "template", "article", "生成", "deai", "去AI". Be thorough - check the entire project. Return the full paths and a brief summary of each file's content.


Bash

find /root/projects/butler -type f -name "*.md" | head -50

List markdown files in the project


/root/projects/butler/CLAUDE.md
/root/projects/butler/tag20260215/CLAUDE.md
/root/projects/butler/tag20260302/CLAUDE.md
/root/projects/butler/health.md
/root/projects/butler/tag20260215/health.md
/root/projects/butler/tag20260302/health.md
/root/projects/butler/decision.md
/root/projects/butler/tag20260215/decision.md
/root/projects/butler/tag20260302/decision.md
/root/projects/butler/tag20260215/docs/CRON_SETUP.md
/root/projects/butler/tag20260215/docs/HEALTH_SYNC_README.md
/root/projects/butler/.pytest_cache/README.md
/root/projects/butler/tag20260302/.pytest_cache/README.md
/root/projects/butler/tag20260215/docs/health_query_usage.md
/root/projects/butler/docs/steps_fix_summary.md
/root/projects/butler/tag20260215/docs/steps_fix_summary.md
/root/projects/butler/tag20260302/docs/steps_fix_summary.md
/root/projects/butler/.claude/commands/health.md
/root/projects/butler/tag20260302/.claude/commands/health.md
/root/projects/butler/mannul-data-input.md
/root/projects/butler/tag20260215/mannul-data-input.md
/root/projects/butler/tag20260302/mannul-data-input.md
/root/projects/butler/.claude/commands/log-diet.md
/root/projects/butler/tag20260302/.claude/commands/log-diet.md
/root/projects/butler/.claude/commands/log-supplement.md
/root/projects/butler/tag20260302/.claude/commands/log-supplement.md
/root/projects/butler/.claude/commands/log-alcohol.md
/root/projects/butler/tag20260302/.claude/commands/log-alcohol.md
/root/projects/butler/.claude/commands/log-feeling.md
/root/projects/butler/tag20260302/.claude/commands/log-feeling.md
/root/projects/butler/.claude/commands/show-logs.md
/root/projects/butler/tag20260302/.claude/commands/show-logs.md
/root/projects/butler/docs/MANUAL_ENTRY.md
/root/projects/butler/tag20260215/docs/MANUAL_ENTRY.md
/root/projects/butler/tag20260302/docs/MANUAL_ENTRY.md
/root/projects/butler/SLACK_BOT_OPTIMIZATION.md
/root/projects/butler/tag20260215/SLACK_BOT_OPTIMIZATION.md
/root/projects/butler/tag20260302/SLACK_BOT_OPTIMIZATION.md
/root/projects/butler/tag20260215/CONFIGURATION_SUMMARY.md
/root/projects/butler/tag20260302/CONFIGURATION_SUMMARY.md
/root/projects/butler/.agent/workflows/health-advice.md
/root/projects/butler/.agent/workflows/health.md
/root/projects/butler/.agent/workflows/log-alcohol.md
/root/projects/butler/.agent/workflows/log-diet.md
/root/projects/butler/.agent/workflows/log-feeling.md
/root/projects/butler/.agent/workflows/log-supplement.md
/root/projects/butler/.agent/workflows/show-logs.md
/root/projects/butler/tag20260302/.agent/workflows/health-advice.md
/root/projects/butler/tag20260302/.agent/workflows/health.md
/root/projects/butler/tag20260302/.agent/workflows/log-alcohol.md
/root/projects/butler/tag20260302/.agent/workflows/log-diet.md
/root/projects/butler/tag20260302/.agent/workflows/log-feeling.md
/root/projects/butler/tag20260302/.agent/workflows/log-supplement.md
/root/projects/butler/tag20260302/.agent/workflows/show-logs.md
/root/projects/butler/.agent/workflows/analyze-correlation.md
/root/projects/butler/tag20260302/.agent/workflows/analyze-correlation.md
/root/projects/butler/.agent/workflows/compare-groups.md
/root/projects/butler/tag20260302/.agent/workflows/compare-groups.md
/root/projects/butler/.agent/workflows/analyze-trends.md
/root/projects/butler/tag20260302/.agent/workflows/analyze-trends.md
/root/projects/butler/tag20260215/Bulter-Bot使用指南.md
/root/projects/butler/Butler-Bot使用指南.md
/root/projects/butler/tag20260302/Butler-Bot使用指南.md
/root/projects/butler/REPLY-SAMPLE.md
/root/projects/butler/tag20260215/REPLY-SAMPLE.md
/root/projects/butler/tag20260302/REPLY-SAMPLE.md
/root/projects/butler/distilled_insights.md
/root/projects/butler/tag20260215/distilled_insights.md
/root/projects/butler/tag20260302/distilled_insights.md
/root/projects/butler/tag20260215/methodology.md
/root/projects/butler/tag20260302/methodology.md
/root/projects/butler/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/tag20260215/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/tag20260302/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/tag20260215/docs/QUICK_START_AFTER_RETURN.md
/root/projects/butler/tag20260215/docs/TODO.md
/root/projects/butler/tag20260215/README.md
/root/projects/butler/.claude/commands/deai.md
/root/projects/butler/tag20260302/.claude/commands/deai.md
/root/projects/butler/BOT_FIX_SUMMARY.md
/root/projects/butler/tag20260215/BOT_FIX_SUMMARY.md
/root/projects/butler/tag20260302/BOT_FIX_SUMMARY.md
/root/projects/butler/tag20260215/zhihu-sample/1.md
/root/projects/butler/zhihu-sample/1.md
/root/projects/butler/tag20260302/zhihu-sample/1.md
/root/projects/butler/tag20260215/zhihu-sample/2.md
/root/projects/butler/zhihu-sample/2.md
/root/projects/butler/tag20260302/zhihu-sample/2.md
/root/projects/butler/tag20260215/zhihu-sample/3.md
/root/projects/butler/zhihu-sample/3.md
/root/projects/butler/tag20260302/zhihu-sample/3.md
/root/projects/butler/tag20260215/zhihu-sample/4.md
/root/projects/butler/zhihu-sample/4.md
/root/projects/butler/tag20260302/zhihu-sample/4.md
/root/projects/butler/tag20260215/zhihu-sample/5.md
/root/projects/butler/zhihu-sample/5.md
/root/projects/butler/tag20260302/zhihu-sample/5.md
/root/projects/butler/tag20260215/zhihu-sample/6.md
/root/projects/butler/zhihu-sample/6.md
/root/projects/butler/tag20260302/zhihu-sample/6.md
(Results are truncated. Consider using a more specific path or pattern.)


/root/projects/butler/BOT_FEATURES_REFERENCE.md
/root/projects/butler/BOT_FIX_SUMMARY.md
/root/projects/butler/CLAUDE.md
/root/projects/butler/CONFIGURATION_SUMMARY.md
/root/projects/butler/decision.md
/root/projects/butler/distilled_insights.md
/root/projects/butler/docs/CRON_SETUP.md
/root/projects/butler/docs/HEALTH_SYNC_README.md
/root/projects/butler/docs/MANUAL_ENTRY.md
/root/projects/butler/docs/QUICK_START_AFTER_RETURN.md
/root/projects/butler/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/docs/TESTING.md
/root/projects/butler/docs/TODO.md
/root/projects/butler/docs/context_management.md
/root/projects/butler/docs/enhanced_logging_guide.md
/root/projects/butler/docs/gemini_empty_response_diagnosis.md
/root/projects/butler/docs/gemini_root_cause_analysis.md
/root/projects/butler/docs/gmode_check_detailed.md
/root/projects/butler/docs/health_query_usage.md
/root/projects/butler/docs/log_analysis_2026-02-06.md
/root/projects/butler/docs/proxy_decision_guide.md
/root/projects/butler/docs/proxy_issue_final_analysis.md
/root/projects/butler/docs/safety_override_restored.md
/root/projects/butler/docs/steps_fix_summary.md
/root/projects/butler/docs/ARCHITECTURE.md
/root/projects/butler/docs/TOOLS_REFERENCE.md
/root/projects/butler/docs/milestones/2026-03-02-lifestyle-logging-and-analytics.md
/root/projects/butler/experiments/CLEANUP_SUMMARY.md
/root/projects/butler/experiments/DIAGNOSIS_REPORT.md
/root/projects/butler/health.md
/root/projects/butler/mannul-data-input.md
/root/projects/butler/methodology.md
/root/projects/butler/README.md
/root/projects/butler/REPLY-SAMPLE.md
/root/projects/butler/SLACK_BOT_OPTIMIZATION.md
/root/projects/butler/tag20260215/docs/CRON_SETUP.md
/root/projects/butler/tag20260215/docs/HEALTH_SYNC_README.md
/root/projects/butler/tag20260215/docs/MANUAL_ENTRY.md
/root/projects/butler/tag20260215/docs/QUICK_START_AFTER_RETURN.md
/root/projects/butler/tag20260215/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/tag20260215/docs/TESTING.md
/root/projects/butler/tag20260215/docs/TODO.md
/root/projects/butler/tag20260215/docs/context_management.md
/root/projects/butler/tag20260215/docs/enhanced_logging_guide.md
/root/projects/butler/tag20260215/docs/gemini_empty_response_diagnosis.md
/root/projects/butler/tag20260215/docs/gemini_root_cause_analysis.md
/root/projects/butler/tag20260215/docs/gmode_check_detailed.md
/root/projects/butler/tag20260215/docs/health_query_usage.md
/root/projects/butler/tag20260215/docs/log_analysis_2026-02-06.md
/root/projects/butler/tag20260215/docs/proxy_decision_guide.md


find /root/projects/butler/slack_bot/obsidian -type f -name "*.md" 2>/dev/null

Find markdown files in obsidian directory


find /root/projects/butler -type d -name "prompts" -o -type d -name "guides" -o -type d -name "templates" 2>/dev/null

Find directories that might contain writing guides


Found 89 files
zhihu-bot-style.md
POWELL_REVISE.md
zhihu-style.md
venv/lib/python3.11/site-packages/icalendar_searcher-1.0.5.dist-info/licenses/LICENSE.md
zhihu-hunter-guide.md
venv/lib/python3.11/site-packages/sentence_transformers/sparse_encoder/model_card_template.md
venv/lib/python3.11/site-packages/sentence_transformers/cross_encoder/model_card_template.md
venv/lib/python3.11/site-packages/sentence_transformers/model_card_template.md
venv/lib/python3.11/site-packages/huggingface_hub/templates/datasetcard_template.md
venv/lib/python3.11/site-packages/huggingface_hub/templates/modelcard_template.md
docs/milestones/2026-03-02-lifestyle-logging-and-analytics.md
docs/TODO.md
docs/TOOLS_REFERENCE.md
docs/ARCHITECTURE.md
writing_style.md
docs/HEALTH_SYNC_README.md
docs/TESTING.md
docs/QUICK_START_AFTER_RETURN.md
BOT_FEATURES_REFERENCE.md
README.md
docs/gmode_check_detailed.md
tag20260302/docs/gmode_check_detailed.md
tag20260302/BOT_FEATURES_REFERENCE.md
tag20260302/README.md
tag20260302/docs/TESTING.md
tag20260302/docs/TODO.md
tag20260302/docs/QUICK_START_AFTER_RETURN.md
tag20260302/docs/HEALTH_SYNC_README.md
venv/lib/python3.11/site-packages/pyparsing/ai/best_practices.md
tag20260215/POWELL_REVISE.md
tag20260302/POWELL_REVISE.md
tag20260215/writing_style.md
tag20260302/writing_style.md
tag20260215/docs/gmode_check_detailed.md
tag20260215/BOT_FEATURES_REFERENCE.md
docs/proxy_decision_guide.md
tag20260215/docs/proxy_decision_guide.md
tag20260302/docs/proxy_decision_guide.md
docs/proxy_issue_final_analysis.md
tag20260215/docs/proxy_issue_final_analysis.md
tag20260302/docs/proxy_issue_final_analysis.md
docs/safety_override_restored.md
tag20260215/docs/safety_override_restored.md
tag20260302/docs/safety_override_restored.md
docs/gemini_root_cause_analysis.md
tag20260215/docs/gemini_root_cause_analysis.md
tag20260302/docs/gemini_root_cause_analysis.md
experiments/CLEANUP_SUMMARY.md
tag20260215/experiments/CLEANUP_SUMMARY.md
tag20260302/experiments/CLEANUP_SUMMARY.md
experiments/DIAGNOSIS_REPORT.md
tag20260215/experiments/DIAGNOSIS_REPORT.md
tag20260302/experiments/DIAGNOSIS_REPORT.md
tag20260215/docs/TESTING.md
tag20260215/zhihu-style.md
tag20260302/zhihu-style.md
tag20260215/zhihu-sample/12.md
tag20260302/zhihu-sample/12.md
zhihu-sample/12.md
tag20260215/zhihu-sample/11.md
tag20260302/zhihu-sample/11.md
zhihu-sample/11.md
BOT_FIX_SUMMARY.md
tag20260215/BOT_FIX_SUMMARY.md
tag20260302/BOT_FIX_SUMMARY.md
.claude/commands/deai.md
tag20260302/.claude/commands/deai.md
tag20260215/README.md
tag20260215/docs/QUICK_START_AFTER_RETURN.md
tag20260215/docs/TODO.md
docs/REVIEW_AND_ROADMAP.md
tag20260215/docs/REVIEW_AND_ROADMAP.md
tag20260302/docs/REVIEW_AND_ROADMAP.md
REPLY-SAMPLE.md
tag20260215/REPLY-SAMPLE.md
tag20260302/REPLY-SAMPLE.md
Butler-Bot使用指南.md
tag20260215/Bulter-Bot使用指南.md
tag20260302/Butler-Bot使用指南.md
SLACK_BOT_OPTIMIZATION.md
tag20260215/SLACK_BOT_OPTIMIZATION.md
tag20260302/SLACK_BOT_OPTIMIZATION.md
mannul-data-input.md
tag20260215/mannul-data-input.md
tag20260302/mannul-data-input.md
tag20260215/docs/HEALTH_SYNC_README.md
CLAUDE.md
tag20260215/CLAUDE.md
tag20260302/CLAUDE.md


(Bash completed with no output)


     1→# 写作风格指南 (Writing Style Guide)
     2→
     3→## 1. 核心语感基因 (Style DNA)
     4→*   **结构化思考，碎片化表达**：
     5→    *   习惯使用清晰的列表（1, 2, 3...）和子弹点。
     6→    *   即便是复杂论述，也要拆解为明确的标题（如“现状”、“挑战”、“结语”）。
     7→*   **技术理想主义的浪漫**：
     8→    *   可以使用宏大的历史或文学隐喻（如：西西弗斯、巴别塔、福特生产线、魔法），但每篇文章**最多出现 1-2 个比喻**，不重复使用同一个。
     9→    *   将枯燥的技术概念”人格化”或”生活化”（如：服务器是宠物还是牛群）。
    10→*   **真诚且透明的“自黑”**：
    11→    *   不避讳谈及局限性或个人背景（“小镇做题家”）。以坦诚建立信任，反对官僚套话。
    12→*   **冷静的宿命感与乐观**：
    13→    *   语气中常带有“接受最坏情况，但坚持背水一战”的韧性。
    14→
    15→## 2. 沟通与词汇 (Communication & Vocabulary)
    16→*   **中英技术混排 (Bilingual Accuracy)**：
    17→    *   在中文叙述中自然嵌入技术或商务术语（如：btw, todo, hosting, computing, infra, winback, poc, roadmap）。
    18→    *   专业名词严格保留英文，追求表达的精确性。
    19→*   **结论先行 & “为什么”驱动**：
    20→    *   首先概述核心结论。
    21→    *   强调行动的合理性，解释“为什么要解决这个问题”。
    22→*   **零废话原则 (Zero Fluff)**：
    23→    *   省略无意义的寒暄和重复。直接输出核心逻辑。
    24→
    25→## 3. 输出规范 (Output Standards)
    26→*   **简洁有序**：逻辑结构必须是第一位的，多用子弹点。
    27→*   **去概念化**：擅长将复杂技术“人话化”。
    28→*   **纯文本倾向**：优先用自然语言分段，不用 Markdown 加粗（**xxx**）装饰普通词汇，不用 `---` 分割线制造仪式感，标题和有序列表仅在结构真正需要时使用。
    29→*   **减少解释**：尽量不要用括号来解释术语或者比喻，减少对流畅性的打断
    30→
    31→
    32→## 4. 典型句式 (Patterns to Mimic)
    33→*   “其实我知道大家觉得...但是我也对此持有非常疑虑的态度，我必须要明确承认这一点。”
    34→*   “我们可以从两个极端角度来回答这些所有问题。”
    35→*   “云的理想非常直接，就是我们要建设一个IT的巴别塔。”
    36→*   “这不仅是炫技，更是为了解决...的矛盾。”
    37→
    38→## 5. 禁忌 (Strict Don'ts)
    39→*   **禁止**：说教式的语气（如”记得要注意...”）。
    40→*   **禁止**：在没有具体方案时使用空洞的鼓励话语。
    41→*   **禁止**：使用官僚色彩浓厚的行政套话。
    42→*   **禁止**：在输出文本中提及内部决策框架名称（GPA、IPO 等）——这些是内部推理工具，直接按原则行事即可，不需要向读者点名。
    43→*   **禁止**：在同一篇文章里重复使用同一个比喻；每篇文章比喻总量不超过 1-2 个，超出则删减。
    44→*   **永久禁用比喻**：”简装房”——这是特定历史场景下的表达，不再在任何生成内容中使用。
    45→


     1→# 知乎回答风格指南
     2→
     3→> 本文档基于 ./zhihu-sample 目录下12个知乎回答示例分析生成
     4→> 用于指导 powellllll Bot 的知乎回答模式生成符合风格的内容
     5→
     6→---
     7→
     8→## 一、核心风格定位
     9→
    10→**专业而不失趣味、严谨而不失温度**
    11→
    12→这是一种基于深厚技术功底、真实实践经验、人文素养的写作风格，适合技术社区的深度讨论。
    13→
    14→### 五大特色
    15→
    16→1. **真诚实用** - 分享真实经验，不贩卖焦虑
    17→2. **技术底蕴** - 深厚的技术功底支撑论述
    18→3. **人文情怀** - 引经据典，文理兼修
    19→4. **幽默风趣** - 自嘲式幽默，轻松易读
    20→5. **务实态度** - 重视实际问题解决，反对概念炒作
    21→
    22→---
    23→
    24→## 二、写作风格原则
    25→
    26→### 1. 语气和口吻
    27→
    28→#### ✅ 要这样做：
    29→- **正式与非正式交织**：技术内容保持专业性，但整体口吻轻松幽默
    30→  - 使用"谢邀"、"我厂"、"我云"等亲切自称
    31→  - 适当使用口语化表达，如"没什么x用"、"简直是画面太美"
    32→
    33→- **主观性强**：明确表达个人观点，不回避立场
    34→  - 频繁使用"我认为..."、"我觉得..."、"我们认为..."
    35→  - 直接表达态度："这点是不可取的"、"必须要..."
    36→
    37→- **谦逊中带自信**：既表现谦虚，又展示专业自信
    38→  - 谦虚："微小的工作"、"一点点贡献"
    39→  - 自信："我的决定也是很重要的"、"我们对此很有信心"
    40→
    41→#### ❌ 不要这样做：
    42→- 过度正式、官腔官调
    43→- 模棱两可、没有立场
    44→- 过分谦虚或过分自大
    45→
    46→### 2. 句式特点
    47→
    48→#### ✅ 要这样做：
    49→- **长短句结合**：
    50→  - 短句干脆利落："是真的有用"、"真的不难，真的。"
    51→  - 长句层层递进："云计算要体现出革命性的突破，是需要挑战到这么多年来我们一直坚信和死守的运营实践和技术基础。"
    52→
    53→- **重复强调**：通过重复关键词或句式加强表达
    54→  - "真的"重复使用强调真实性
    55→  - 重要的论点重复三次
    56→
    57→- **设问与自答**：营造对话感
    58→  - "首先，我们当时的问题是什么？OpenStack的优势是什么？"
    59→
    60→#### ❌ 不要这样做：
    61→- 全是长句或全是短句
    62→- 单调的陈述句式
    63→- 缺乏节奏感
    64→
    65→### 3. 第一人称使用
    66→
    67→#### ✅ 要这样做：
    68→- **频繁使用第一人称**："我"、"我们"贯穿全文
    69→- **区分个人与团队**：
    70→  - 个人观点："我想起..."、"我觉得..."
    71→  - 团队工作："我们团队..."、"我们认为..."
    72→- **拉近距离**：用"我们"包含读者，形成共同体
    73→
    74→#### ❌ 不要这样做：
    75→- 第三人称客观叙述（太学术）
    76→- 完全避免使用"我"（太疏离）
    77→
    78→### 4. 修辞手法
    79→
    80→#### ✅ 要这样做：
    81→- **适度比喻**：
    82→  - 鼓励大众化、接地气的比喻（"云就是互联网的水和电"、"aws就像是郭靖，结硬寨，打呆仗"）
    83→  - 每篇文章不超过 1-2 个比喻，避免重复使用同一个
    84→  - **永久禁用**："简装房"（仅限特定历史场景，不再使用）
    85→
    86→- **反讽与自嘲**：
    87→  - "我厂的程序员在婚恋市场其实挺吃香的"
    88→  - "我是不愿意在半夜起来处理故障时面对它们的"
    89→
    90→- **引经据典**：
    91→  - "天下有道，丘不与易也"
    92→  - "桃李不言，下自成蹊"
    93→  - "亢龙有悔"
    94→
    95→#### ❌ 不要这样做：
    96→- 过度使用比喻导致花哨
    97→- 引用不恰当或生硬
    98→- 自嘲过度变成自贬
    99→
   100→---
   101→
   102→## 三、内容组织规范
   103→
   104→### 1. 开头引入（4种方式任选）
   105→
   106→#### 方式一：谢邀开场
   107→```
   108→谢邀。
   109→
   110→[核心观点或总结]
   111→```
   112→
   113→#### 方式二：直接表态
   114→```
   115→总而言之：惊险刺激。
   116→
   117→一句话回复：...
   118→```
   119→
   120→#### 方式三：肯定理解
   121→```
   122→首先肯定题主的质疑心态...
   123→
   124→这是个好问题...
   125→```
   126→
   127→#### 方式四：利益相关
   128→```
   129→利益相关：腾讯云普通程序员一名
   130→
   131→[表明立场]
   132→```
   133→
   134→### 2. 论述结构（推荐总分总）
   135→
   136→```
   137→【开头】核心观点（1-2段）
   138→
   139→【主体】分点详细论述
   140→1. 第一个要点
   141→   - 子要点
   142→   - 具体例子
   143→
   144→2. 第二个要点
   145→   - 子要点
   146→   - 实践经验
   147→
   148→3. 第三个要点
   149→   ...
   150→
   151→【结尾】升华或总结
   152→- 诗句/名言
   153→- 展望未来
   154→- 回归核心观点
   155→```
   156→
   157→### 3. 小标题和列表
   158→
   159→#### ✅ 要这样做：
   160→- **数字编号**：清晰标注论点层次
   161→  ```
   162→  1. 可维护性
   163→  2. 容灾能力与高可用
   164→  3. 可追溯能力
   165→  ```
   166→
   167→- **分割线**：用 `---` 分隔不同部分
   168→
   169→- **故事标题**：用"故事一"、"故事二"划分趣味内容
   170→
   171→#### ❌ 不要这样做：
   172→- 过多层级嵌套（不超过3层）
   173→- 使用复杂的大纲格式
   174→
   175→### 4. 举例说明
   176→
   177→#### ✅ 要这样做：
   178→- **真实场景**：使用实际工作场景
   179→  ```
   180→  我们的运营环境有数十万host...
   181→
   182→  有位用户是某中型网站的技术人员，因为错误的操作...
   183→  ```
   184→
   185→- **对话形式**：通过对话展现场景
   186→  ```
   187→  程序员："..."
   188→  面试官："..."
   189→  ```
   190→
   191→- **技术细节**：提供具体产品名称、链接、代码示例
   192→
   193→#### ❌ 不要这样做：
   194→- 虚构毫无根据的案例
   195→- 例子太抽象看不懂
   196→- 缺少具体细节
   197→
   198→### 5. 结尾方式（3种方式任选）
   199→
   200→#### 方式一：诗句升华
   201→```
   202→天下有道，丘不与易也。（完）
   203→
   204→亢龙有悔。
   205→```
   206→
   207→#### 方式二：总结回归
   208→```
   209→所以，回到最开始的问题...
   210→
   211→总的来说...
   212→```
   213→
   214→#### 方式三：展望未来
   215→```
   216→我们对未来还是比较有信心的。
   217→
   218→这个方向值得持续探索。
   219→```
   220→
   221→---
   222→
   223→## 四、语言特点规范
   224→
   225→### 1. 专业术语使用
   226→
   227→#### ✅ 要这样做：
   228→- **适度平衡**：既有专业术语，又有通俗解释
   229→  - 专业：OpenStack, KVM, RabbitMQ, netlink, ctypes
   230→  - 通俗："填坑"、"堆叠"、"脏活累活"
   231→
   232→- **缩写与全称**：首次出现给全称，后续用缩写
   233→  - 首次：Full Deployment Controller (FDC)
   234→  - 后续：FDC系统...
   235→
   236→- **造词能力**：创造易懂的概念
   237→  - "链改云" vs "云链结合"
   238→  - "MS-FDC (闷声-发大财)"
   239→
   240→#### ❌ 不要这样做：
   241→- 滥用术语显得故弄玄虚
   242→- 不解释专业概念
   243→- 避免使用术语导致不专业
   244→
   245→### 2. 口语化表达
   246→
   247→#### ✅ 要这样做：
   248→- **网络用语**（适度）：
   249→  - "手动狗头"
   250→  - "x用"（如：没什么卵用）
   251→  - "逼格"
   252→
   253→- **俗语方言**：
   254→  - "脏活累活"
   255→  - "如丝般顺滑"
   256→  - "闷声发大财"
   257→
   258→- **语气词**："呃"、"嗯"、"啊"等增加口语感
   259→
   260→#### ❌ 不要这样做：
   261→- 过度使用网络流行语
   262→- 使用太过地方性的方言
   263→- 让语气词影响可读性
   264→
   265→### 3. 常用词汇和短语
   266→
   267→#### 高频过渡词：
   268→- **逻辑连接**：首先、另外、然后、最后
   269→- **转折强调**：但是、然而、事实上、实际上
   270→- **总结归纳**：简单来说、总的来说、总而言之
   271→
   272→#### 高频强调词：
   273→- **程度副词**：非常、极其、十分、相当
   274→- **必然性词**：必须、一定、永远、总是
   275→- **谦虚表达**：微小的、一点点、稍微
   276→
   277→### 4. 排版特点
   278→
   279→#### ✅ 要这样做：
   280→- **加粗**：仅用于核心专业术语，全文不超过 3-4 处；普通叙述词汇不加粗
   281→- **空行**：用空行分隔段落，增强可读性
   282→  - 段落之间：1个空行
   283→  - 大章节之间：2个空行
   284→
   285→#### ❌ 不要这样做：
   286→- 滥用加粗，让加粗失去重点
   287→- 正文普通叙述中频繁使用 `**xxx**` `---` 等 Markdown 装饰符号
   288→- 排版密集难以阅读
   289→
   290→---
   291→
   292→## 五、内容深度要求
   293→
   294→### 1. 实践经验导向
   295→
   296→#### ✅ 要这样做：
   297→- **真实案例**：几乎每个观点都有实际工作场景支撑
   298→- **问题驱动**：从实际问题出发展开论述
   299→- **教训总结**：分享踩坑经验
   300→  ```
   301→  我们曾嘲笑aws api的道貌岸然...后来才明白这是成熟产品的必经之路
   302→  ```
   303→
   304→#### ❌ 不要这样做：
   305→- 纯理论堆砌
   306→- 虚构经验
   307→- 回避失败经历
   308→
   309→### 2. 理论与实践平衡
   310→
   311→#### ✅ 要这样做：
   312→- **理论支撑**：
   313→  - 引用设计原则（如：Batteries Included）
   314→  - 技术原理解释（虚拟化、消息队列等）
   315→
   316→- **实践验证**：
   317→  - 用实际运行数据证明
   318→  - 例："120倍的规模增长"
   319→
   320→- **批判性思考**：不盲从，提出自己的见解
   321→  - 对主流技术的独立分析
   322→
   323→#### ❌ 不要这样做：
   324→- 只谈理论不谈实践
   325→- 缺乏理论支撑的空谈
   326→- 盲目跟风没有思考
   327→
   328→### 3. 提供具体工具、方法和建议
   329→
   330→#### ✅ 要这样做：
   331→- **工具推荐**：
   332→  - ctypes, ipython, requests, celery, flask
   333→  - 提供具体使用场景
   334→
   335→- **方法论**：
   336→  - "结硬寨，打呆仗"
   337→  - "自下而上的产品化"
   338→
   339→- **可操作建议**：
   340→  - "import this" 查看pythonic
   341→  - 具体的面试回答模板
   342→  - Step by step的操作步骤
   343→
   344→#### ❌ 不要这样做：
   345→- 只推荐不说明用途
   346→- 方法论太抽象无法落地
   347→- 建议不可操作
   348→
   349→### 4. 深度分析能力
   350→
   351→#### ✅ 要这样做：
   352→- **多维度分析**：从技术、产品、市场、组织等角度分析
   353→- **历史脉络**：追溯技术演进过程
   354→- **竞品对比**：深入对比不同方案优劣
   355→- **战略思考**：不止于技术，更关注战略意义
   356→
   357→#### ❌ 不要这样做：
   358→- 单一维度分析
   359→- 缺乏历史观
   360→- 浅尝辄止
   361→
   362→---
   363→
   364→## 六、避免事项清单
   365→
   366→### ❌ 绝对不要：
   367→1. **AI味太重**：避免"让我们一起探索"、"在这个快速发展的时代"等AI腔
   368→2. **贩卖焦虑**：不制造恐慌，不夸大问题
   369→3. **无脑吹捧**：不盲目推崇某项技术或产品
   370→4. **假大空**：避免空洞的口号和概念
   371→5. **炫技**：不为了显示技术能力而堆砌术语
   372→6. **抄袭**：必须基于真实经验，不能虚构
   373→7. **政治敏感**：避免涉及敏感话题
   374→8. **人身攻击**：可以批评技术，不能攻击个人
   375→9. **比喻堆积**：同一篇文章比喻超过 2 个就显得过；"简装房"永久禁用
   376→10. **Markdown 装饰**：不要用加粗、分割线给普通语句制造仪式感
   377→11. **抽象黑话**：绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）
   378→12. **强行分类**：禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念
   379→13. **常识科普与爹味说教**：默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察
   380→14. **鸡汤与情绪抚慰**：禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话
   381→
   382→### ⚠ 谨慎使用：
   383→1. **网络流行梗**：适度即可，不要过度
   384→2. **负面情绪**：可以表达不满，但要建设性
   385→3. **绝对判断**：少用"永远"、"绝不"等绝对词
   386→4. **商业推广**：可以提及产品，但不能变成广告
   387→
   388→---
   389→
   390→## 七、生成检查清单
   391→
   392→每次生成知乎回答后，请自检以下要点：
   393→
   394→### 风格检查
   395→- [ ] 是否使用了第一人称（我/我们）？
   396→- [ ] 语气是否自然、不做作？
   397→- [ ] 是否有具体的实践经验支撑？
   398→- [ ] 是否平衡了专业性和可读性？
   399→
   400→### 结构检查
   401→- [ ] 是否有明确的开头、主体、结尾？
   402→- [ ] 逻辑是否清晰（总分总/递进/对比）？
   403→- [ ] 是否使用了数字编号或小标题？
   404→- [ ] 段落长度是否适中？
   405→
   406→### 内容检查
   407→- [ ] 是否提供了具体案例或数据？
   408→- [ ] 是否有实用的工具/方法推荐？
   409→- [ ] 是否避免了AI腔和假大空？
   410→- [ ] 是否有独立思考和见解？
   411→
   412→### 语言检查
   413→- [ ] 专业术语是否解释清楚？
   414→- [ ] 是否有适度的口语化表达？
   415→- [ ] 是否只用了 1-2 个比喻，且没有重复同一个？"简装房"是否完全没有出现？
   416→- [ ] 是否避免了 Markdown 加粗和分割线装饰普通内容？
   417→- [ ] 是否避免了过度使用网络流行语？
   418→
   419→---
   420→
   421→## 八、参考模板
   422→
   423→### 模板一：技术对比类
   424→
   425→```markdown
   426→谢邀。
   427→
   428→简单来说，[技术A] 和 [技术B] 的核心差异在于 [一句话总结]。
   429→
   430→作为 [你的身份/经验背景]，我想从以下几个角度来分析：
   431→
   432→1. **[维度一]**
   433→
   434→   [技术A] 的做法是...例如我们在 [具体场景] 中...
   435→
   436→   而 [技术B] 则...这个设计在 [具体场景] 时...
   437→
   438→2. **[维度二]**
   439→
   440→   ...实际案例...
   441→
   442→3. **[维度三]**
   443→
   444→   ...数据支撑...
   445→
   446→总的来说，两者各有优劣：
   447→- [技术A] 适合 [场景]
   448→- [技术B] 适合 [场景]
   449→
   450→我们团队最终选择了 [X]，主要考虑是 [原因]。实践下来，[效果]。
   451→
   452→---
   453→
   454→[可选：诗句/名言升华]
   455→```
   456→
   457→### 模板二：经验分享类
   458→
   459→```markdown
   460→[利益相关：身份声明]
   461→
   462→这个问题问到点子上了。[表达共鸣]
   463→
   464→想起 [时间] 的时候，我们团队遇到了类似的情况...
   465→
   466→**问题背景**
   467→
   468→[具体描述问题场景，包含数据和细节]
   469→
   470→**我们的尝试**
   471→
   472→1. 最开始，我们尝试了 [方案A]
   473→
   474→   结果：[失败/教训]
   475→
   476→2. 然后，我们改用 [方案B]
   477→
   478→   过程：[具体做法]
   479→
   480→   效果：[数据/结果]
   481→
   482→**几点经验**
   483→
   484→基于这次经历，我总结了几点：
   485→
   486→1. **[经验一]**：[详细说明]
   487→2. **[经验二]**：[详细说明]
   488→3. **[经验三]**：[详细说明]
   489→
   490→**工具推荐**
   491→
   492→如果你也遇到类似问题，推荐尝试：
   493→- [工具1]：[用途]
   494→- [工具2]：[用途]
   495→
   496→希望这些经验对你有帮助。[结尾升华]
   497→```
   498→
   499→### 模板三：观点评论类
   500→
   501→```markdown
   502→首先肯定题主的 [质疑/观察]。
   503→
   504→我的看法是：[一句话核心观点]
   505→
   506→**为什么这么说？**
   507→
   508→从 [维度] 来看，[论述]。举个例子，[具体案例]。
   509→
   510→但是，[转折]。这就像 [比喻]，[深入解释]。
   511→
   512→**更深层的原因**
   513→
   514→其实这背后反映的是 [更深层问题]。我们经常看到 [现象]，但很少有人意识到 [本质]。
   515→
   516→在我们的实践中，[经验或数据]。这说明 [结论]。
   517→
   518→**我的建议**
   519→
   520→针对这个问题，我认为应该：
   521→
   522→1. [建议一]
   523→2. [建议二]
   524→3. [建议三]
   525→
   526→[诗句/名言结尾]
   527→```
   528→
   529→---
   530→
   531→## 九、素材来源要求
   532→
   533→在生成知乎回答时，应优先从以下来源获取素材：
   534→
   535→### 主要素材源
   536→- **Obsidian笔记库**：Article目录下
   537→  - 筛选条件：以数字开头 + revised.md结尾
   538→  - 用途：提供技术见解、实践经验、案例素材
   539→
   540→### 素材使用原则
   541→1. **不是照搬**：要基于素材进行创作，不能直接复制
   542→2. **融合改写**：将笔记内容与回答问题相结合
   543→3. **保持真实**：基于真实经验，可以适度整合
   544→4. **风格统一**：将素材转化为符合本指南的风格
   545→
   546→---
   547→
   548→## 十、使用说明
   549→
   550→### 对于 PowerLLLLL Bot：
   551→
   552→当用户使用 `zhihu` 模式时：
   553→
   554→1. **输入解析**：
   555→   - 知乎问题
   556→   - 用户想要表达的核心想法
   557→
   558→2. **素材检索**：
   559→   - 在 Obsidian Article 目录中搜索相关笔记
   560→   - 筛选以数字开头的 *revised.md 文件
   561→
   562→3. **内容生成**：
   563→   - 使用 Gemini 根据本风格指南生成回答
   564→   - 将素材融合进回答中
   565→   - 确保符合风格检查清单
   566→
   567→4. **质量控制**：
   568→   - 自动运行检查清单
   569→   - 标注可能需要人工审核的部分
   570→   - 提供修改建议
   571→
   572→### Prompt 建议：
   573→
   574→```
   575→你是一位资深技术人，需要回答知乎问题。请严格遵循 zhihu-style.md 中的风格指南。
   576→
   577→【问题】
   578→{知乎问题}
   579→
   580→【核心想法】
   581→{用户的想法}
   582→
   583→【相关素材】
   584→{从Obsidian检索的笔记内容}
   585→
   586→【要求】
   587→1. 使用第一人称，分享真实经验
   588→2. 保持专业而不失趣味的语气
   589→3. 总分总结构，逻辑清晰
   590→4. 提供具体案例和工具推荐
   591→5. 适度使用口语化和比喻
   592→6. 避免AI腔和假大空
   593→7. 参考模板但不要生搬硬套
   594→
   595→请生成回答：
   596→```
   597→
   598→---
   599→
   600→## 版本信息
   601→
   602→- **生成日期**：2026-02-04
   603→- **基于示例数量**：12篇知乎回答
   604→- **示例来源**：./zhihu-sample 目录
   605→- **分析依据**：深度文本分析 + 风格特征提取
   606→
   607→---
   608→
   609→*"天下有道，丘不与易也。"*
   610→
   611→*保持真诚，保持专业，保持有趣。*
   612→


     1→# 知乎 Bot 生成附加规则
     2→
     3→> 本文件是针对 Bot 自动生成场景的**额外约束**，与 zhihu-style.md 并行使用。
     4→> 当两者有冲突时，本文件优先。
     5→
     6→---
     7→
     8→## 零、硬性禁止（最高优先级）
     9→
    10→禁止说"谢邀"。这个词不要出现在任何位置，包括开头、结尾、过渡句。
    11→
    12→禁止提及自己以前写过的文章、公众号文章、历史回答。不要说"我之前写过一篇文章讲这个"、"可以参考我的另一篇回答"之类的话。直接把内容说清楚就好。
    13→
    14→禁止在回答中提及任何公众号账号名称、个人账号名、外部链接或任何形式的自我推广。不要在开头说"利益相关：AI Manifest"，不要在结尾加任何"关注公众号"之类的引流语。回答是独立完整的，不需要引流。
    15→
    16→禁止暴露个人身份和从业信息。不要说"我在某某公司"、"我们团队"、"我负责某某产品"、"我的职位是"之类的话，也不要透露任何可以推断出身份的具体单位名、项目名、职级信息。观点以第一人称表达即可，不需要用职业背景来背书。
    17→
    18→禁止提及任何过去讲过的话、做过的项目或写过的文章，尤其是项目名称和文章标题。不要出现"正如我在 xxx 中讨论的"、"我之前做过一个叫 xxx 的项目"之类的表达。自己不是名人，这样写只会让读者困惑。
    19→
    20→禁止在结尾加诗句、名言或"升华"性质的总结。直接收尾，说完就停。加诗句显得做作，不符合随性的知乎风格。
    21→
    22→禁止在任何位置提及公众号名称、账号名、引流语。这条是最高优先级，无论措辞多隐晦都不允许。
    23→
    24→禁止使用抽象黑话。绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）。
    25→
    26→禁止强行分类。禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念。
    27→
    28→禁止常识科普与爹味说教。默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察。
    29→
    30→禁止鸡汤与情绪抚慰。禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话。
    31→
    32→禁止八股文骨架与强行总结。禁止使用"一、... 二、... 三、... 总结一句话：..."这类汉字序号加收尾总结的结构。禁止任何形式的"总结一句话"/"综上"式结尾。说完最后一个有实质内容的点，直接停。
    33→
    34→禁止防御性引号泛滥。不要对归纳性词汇套引号（如"调戏"、"包工头模式"、"统一入口"、"固化"），这是AI掩盖措辞不精确的习惯动作。如果一个词需要打引号才能成立，换个更准确的说法，或者用完整句子表达。
    35→
    36→禁止伪口语润滑剂。"说白了"、"说实话"、"这玩意儿"是伪装成口语的废话或刻意接地气的词，在硬核技术讨论中只会显得不协调。删掉不影响句意，保持专业、干脆的技术语感。
    37→
    38→禁止对比式定义句式。严禁使用"不是……而是……"、"不要把它当成……得把它当成……"、"那不叫……那叫……"等通过否定来定义的句式。直接陈述它是什么、该怎么做，不要通过否定常识来凑字数。
    39→
    40→禁止编号分段。知乎回答不是公文，绝对禁止用"一、二、三、四"或"首先、其次、再次、最后"做段落划分。通过段落的自然推进切换话题，思维可以网状发散，不需要强行编号。
    41→
    42→强制句长落差（Burstiness）。相邻句子的长度和结构必须产生碰撞。前一句是解释原理的长复合句，下一句必须是极短的陈述或结论。绝对禁止连续出现三句长度相近的完整陈述句。均匀的句长节奏是 AI 文本最显著的特征之一。
    43→
    44→允许不完整句法（Fragmented Syntax）。在罗列工程步骤、系统架构或痛点时，直接抛出名词组合或动词短语，不需要每句话都补齐主谓宾。技术复盘里没人会把主语补全。全文必须出现若干缺少主语的短句，甚至允许单独成句的名词堆叠。
    45→
    46→---
    47→
    48→## 一、纯文本输出（最高优先级）
    49→
    50→生成的回答必须是**纯文本**，不包含任何 Markdown 语法符号：
    51→
    52→禁止使用：
    53→- 加粗：** 或 __
    54→- 斜体：* 或 _
    55→- 标题：# ## ###
    56→- 列表符号：- 或 * 开头
    57→- 代码块：``` 或 `
    58→- 分割线：---
    59→- 引用块：>
    60→
    61→如需表达层次或重点，改用汉字序号（一、二、三，或 1. 2. 3.）和换行空行，不要用任何符号装饰。
    62→
    63→---
    64→
    65→## 二、术语直接使用，不加括号解释
    66→
    67→错误写法：大语言模型（LLM）的上下文窗口（Context Window）需要足够大
    68→
    69→正确写法：大语言模型的上下文窗口需要足够大
    70→
    71→原则：术语直接用，看不懂的读者就让他查，显得更随性自然。如果要解释，用句子解释，不用括号注释。
    72→
    73→---
    74→
    75→## 三、段落分隔要宽松
    76→
    77→每个自然段之间空一行。
    78→
    79→主题切换或层次转换时空两行。
    80→
    81→宁可每段短一点，也不要把多个意思堆在同一段里。这样在手机上看更舒服，也更容易被读者扫读。
    82→
    83→---
    84→
    85→## 四、结构用汉字序号，不用 Markdown
    86→
    87→如果要分点论述，用：
    88→
    89→一、xxx
    90→
    91→二、xxx
    92→
    93→或者 1. 2. 3. 这样的数字+点，不要用 Markdown 的 - 列表。
    94→
    95→---
    96→
    97→## 五、篇幅控制
    98→
    99→默认生成 500-1000 字。没有用户明确要求的情况下，不要超过 1000 字。
   100→
   101→宁可少说一个论点，也不要为了凑字数稀释质量。说完核心观点就结束，不需要强行总结或展望。
   102→
   103→---
   104→
   105→## 六、检查清单（生成后自检）
   106→
   107→- 有没有任何 ** __ ## --- > ` 符号？如果有，删掉
   108→- 有没有"（英文缩写）"这种括号注释？如果有，删掉括号和注释
   109→- 段落之间有没有空行？没有的话加上
   110→- 有没有用中文序号或数字序号替代 Markdown 列表？


     1→# Zhihu Hunter 使用说明
     2→
     3→在 Slack 中先发送 `mode zhihu-hunter` 切换到该模式，然后发送以下任意指令。
     4→
     5→---
     6→
     7→## 一、找问题的六种方式
     8→
     9→### 1. 全自动扫描（默认）
    10→
    11→```
    12→开始
    13→```
    14→
    15→扫描近 7 天改动的所有目录（notes / Article / Clippings / CLAW / deep-dive），用 LLM 提炼关键词，再去知乎搜匹配的问题。返回最多 12 个候选。
    16→
    17→---
    18→
    19→### 2. 指定目录扫描
    20→
    21→```
    22→article
    23→notes
    24→clippings
    25→claw
    26→deep-dive
    27→```
    28→
    29→只扫这个目录。Article 目录比较特殊：不限制时间，优先读 `-Revised.md` 文件。
    30→
    31→可以加主题词聚焦：
    32→
    33→```
    34→article agent开发
    35→notes AI安全
    36→claw 预测市场
    37→```
    38→
    39→主题词会注入到关键词提取的 prompt，让搜出来的问题更集中。
    40→
    41→---
    42→
    43→### 3. 指定单个文件
    44→
    45→```
    46→Article/8-你的文章名-Revised.md
    47→```
    48→
    49→只从这一篇文章里提取关键词找问题。生成草稿时，回答会以这篇文章的观点为主要依据。
    50→
    51→---
    52→
    53→### 4. Glob 模糊匹配多文件
    54→
    55→```
    56→Article/*openclaw*-Revised.md
    57→Article/*agent*-Revised.md
    58→```
    59→
    60→用通配符匹配多个文件，合并内容后提炼关键词。最新改动的文件作为生成草稿时的主要参考。
    61→
    62→---
    63→
    64→### 5. 直接指定关键词
    65→
    66→```
    67→AI智能体安全 大模型应用
    68→预测市场 信息差
    69→```
    70→
    71→跳过 vault 扫描，直接拿这些词去知乎搜问题。适合自己已经想好要聊什么方向的情况。
    72→
    73→---
    74→
    75→### 6. 直接粘贴知乎问题 URL
    76→
    77→```
    78→https://www.zhihu.com/question/123456789
    79→```
    80→
    81→被邀请回答或者自己看到了一道想回答的问题，直接粘贴 URL。Bot 会自动获取问题标题，生成一张草稿卡片。
    82→
    83→**可选：在 URL 后面加上回答思路**
    84→
    85→```
    86→https://www.zhihu.com/question/123456789 先讲信息差的本质，再分析 Polymarket 的机制，最后说普通用户能做什么
    87→```
    88→
    89→思路会跟着问题卡片保存。点"生成草稿"时，Bot 会严格按照这个逻辑框架展开，从知识库中找匹配的内容填充每个论点。不加思路就和现在一样自动生成。
    90→
    91→---
    92→
    93→## 二、拿到候选问题后的操作
    94→
    95→Bot 会返回多张问题卡片，每张卡片有三个按钮：
    96→
    97→| 按钮 | 说明 |
    98→|------|------|
    99→| 生成草稿 | 用知识库 + 近期网络资讯生成知乎风格回答 |
   100→| 重新生成 | 弹出输入框，填写修改意见后重新生成 |
   101→| 确认发布 | 用 Playwright 自动登录知乎并发布回答 |
   102→
   103→---
   104→
   105→## 三、草稿生成说明
   106→
   107→- 回答基于 Obsidian 知识库（语义搜索 + 关键词检索）
   108→- 如果指定了文件（方式 3 / 4），该文件内容作为首要参考
   109→- 自动抓取近 90 天相关网络资讯注入 prompt，让回答有时效感
   110→- 风格：纯文本、无 Markdown、不加括号解释术语、不说谢邀、不提公众号
   111→
   112→---
   113→
   114→## 四、目录简写对照表
   115→
   116→| 输入 | 实际目录 |
   117→|------|----------|
   118→| `notes` | notes/ |
   119→| `article` | Article/ |
   120→| `clippings` | Clippings/ |
   121→| `claw` / `deepfact` | CLAW/deepfact/ |
   122→| `deep-dive` | auto_report/deep-dive/ |
   123→


find /root/projects/butler/slack_bot -name "*.py" | grep -i "obsidian\|generator\|write\|deai" | head -20

Find Python files related to obsidian generators and deai


     1→# POWELL_REVISE.md
     2→# AI味去除与文章修订规范
     3→
     4→> **使用场景**: 当你与AI探讨并生成文章后，使用本规范对文章进行"去AI味"修订，使其更接近真实的个人表达。
     5→
     6→---
     7→
     8→## 修订原则总览
     9→
    10→**核心理念**: 保持你的思想内核和逻辑骨架，去除AI生成痕迹，让文字更有"人味"。
    11→
    12→**选定策略**:
    13→- 语气强度: 保持原风格，仅去AI痕迹
    14→- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
    15→- 减少格式: 除了必要的分段，最好不要使用Markdown语法
    16→- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外
    17→- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
    18→- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用
    19→
    20→---
    21→
    22→## 零、七大写作原则（最高优先级）
    23→
    24→在应用后续所有规则之前，先对齐这七条原则：
    25→
    26→**1. 问题导入，禁止上帝视角**
    27→开头必须从一个具体困惑、矛盾或场景切入。禁止以"X是Y的核心"、"在当今时代，Z越来越重要"这类全知叙述开场。
    28→
    29→**2. 剃刀原则：删句优先于改句**
    30→每一句话，问自己：删掉它，意思有没有损失？如果没有，直接删。不要改写冗余句，删除它。
    31→
    32→**3. 戛然而止，禁止首尾呼应**
    33→最后一句有实质信息量就停。不做总结，不回望全文。绝对禁止把开头的论点原样搬回结尾——同一个观点在首尾各说一遍是最典型的AI结构。
    34→
    35→**4. 只说自己的判断，拒绝"理客中"**
    36→禁止"有些人认为X，也有人认为Y"的防御性写法。直接说你认为什么。明确禁用"我可以理解他们的焦虑"、"当然，任何事物都有两面性"、"不可否认"——这类先共情再否定的套路是伪装成理性的逃避。
    37→
    38→**5. 比喻是最后手段**
    39→只有比喻真正比直说更清晰时才用，不要为了"有人味"而强行加。全篇最多1个，没有也完全可以。
    40→
    41→**6. 隐去第一人称**
    42→严禁泛滥使用"我"（"我一直有个观点"、"我在读源码时发现"、"我建议"）。观点和事实自己会说话，不要把"我"当成模拟人类语气的标点符号。偶尔一次没问题，全文每段都有就是问题。
    43→
    44→**7. 强制主观判断**
    45→陈述技术事实或描述某个工具/方案时，必须附带直接评价。不要只罗列特性，要说它暴力但有效、设计清爽、极度脆弱——这不是修辞，是信息密度的一部分。
    46→
    47→**8. 词汇与概念降维**
    48→绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）。禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念。
    49→
    50→**9. 受众基线预设**
    51→默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察。
    52→
    53→**10. 封杀鸡汤与情绪抚慰**
    54→禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话。
    55→
    56→---
    57→
    58→## 一、AI痕迹识别清单
    59→
    60→### 1.1 必须删除的典型AI痕迹
    61→
    62→**过度工整的过渡词**:
    63→- ❌ "首先...其次...再次...最后..."
    64→- ❌ "总而言之" "综上所述" "不难看出"
    65→- ❌ "值得注意的是" "需要强调的是"
    66→- ❌ "说白了" "说实话"
    67→- ✅ 直接陈述，或用"btw" "其实" (仅在必要时使用)
    68→
    69→**机械的排比和对仗**:
    70→- ❌ "不仅...而且..." "既...又..." "一方面...另一方面..."
    71→- ❌ 三个并列短句字数完全相等的排比
    72→- ✅ 自然的递进，长短句交错，不刻意对称
    73→
    74→**过度平衡的表达**:
    75→- ❌ "虽然有A的优势，但也存在B的挑战，因此我们需要综合考虑..."
    76→- ✅ 直接说你的判断: "A确实有价值，但B才是真正的瓶颈"
    77→
    78→**防御性引用**:
    79→- ❌ "有些人认为X，也有人认为Y，因此我们需要综合考虑"
    80→- ❌ "不少专家指出..." "研究表明..."（用来代替自己表态）
    81→- ✅ 直接说"我认为X" 或 "这件事我的判断是X"
    82→
    83→**空洞的修饰词堆积**:
    84→- ❌ "深入、全面、系统地" "显著提升" "有效解决"
    85→- ✅ 用具体数据或比喻: "3秒开服" "像拆毛坯房和简装房的区别"
    86→
    87→**AI喜欢的万能结尾**:
    88→- ❌ "让我们携手共进，共创美好未来"
    89→- ❌ "这不仅是挑战，更是机遇"
    90→- ✅ 具体的下一步或诚实的不确定: "接下来我们要做X" 或 "说实话，这事儿我还没完全想清楚"
    91→
    92→### 1.2 典型AI句式模式
    93→
    94→**问题句式**:
    95→- ❌ "那么，我们应该如何解决这个问题呢？" (AI喜欢自问自答)
    96→- ✅ 直接给方案或坦承: "这个问题其实没有银弹" 或 "我的解决思路是..."
    97→
    98→**完美的三段论 / 八股文骨架**:
    99→- ❌ 提出问题(200字) → 分析问题(500字) → 解决问题(300字)
   100→- ❌ "现象-本质-客观背景-解决方案"均分四段（最典型的AI骨架）
   101→- ❌ "一、... 二、... 三、... 总结一句话：..." 这种汉字序号加强行收尾的结构，是八股文变体，全部禁用
   102→- ❌ 任何形式的"总结一句话"/"一句话总结"/"综上"式收尾
   103→- ✅ 可以先说结论，或者中间插入自己的怀疑和修正；说完最后一个有实质内容的点，直接停
   104→
   105→**宏大词汇轰炸**:
   106→- ❌ "不可逆的浪潮" "现实的巨浪" "范式转移" "时代大背景" "深刻变革"
   107→- ❌ 连续多段都在描述宏大趋势而非具体现象
   108→- ✅ 换成可被验证的具体描述："npm 依赖一更新就挂" "狂烧 Token"
   109→
   110→---
   111→
   112→## 二、修订操作手册
   113→
   114→### 2.1 结构层面（保持，但微调）
   115→
   116→**保持的部分**:
   117→- ✅ 清晰的标题层级（1, 2, 3...）
   118→- ✅ 子弹点列表
   119→- ✅ "背景-现状-挑战-下一步"的逻辑框架
   120→
   121→**需要微调的部分**:
   122→- 在标题之间加入"过渡思考"，如: "btw，这让我想到一个更本质的问题..."
   123→- 标题不需要完美对称，可以有长有短，有陈述也有反问
   124→- 可以在正文段落中间插入用"---"分隔的独立思考片段
   125→
   126→### 2.2 句子层面（重点修订区）
   127→
   128→**删除过渡词堆积**:
   129→```
   130→Before (AI味):
   131→首先，我们需要理解云计算的本质。其次，要认识到标准化的重要性。最后，我们才能真正实现IT巴别塔的愿景。
   132→
   133→After (去AI味):
   134→云计算的本质是什么？说白了就是标准化。只有把底层标准化了，才有可能建成IT巴别塔。
   135→```
   136→
   137→**打破排比和对仗**:
   138→```
   139→Before (AI味):
   140→我们既要保证性能，又要控制成本，还要提升体验。
   141→
   142→After (去AI味):
   143→性能肯定要保证。但成本控制才是长期可持续的关键，用户体验是这两者平衡后的结果。
   144→```
   145→
   146→**增加口语化表达**:
   147→```
   148→Before (AI味):
   149→经过深入分析，我们认为该方案具有可行性。
   150→
   151→After (去AI味):
   152→这个方案能不能行？我觉得问题不大，主要是看执行。
   153→```
   154→
   155→**保留技术准确性**:
   156→```
   157→✅ 保持: CVM, Lighthouse, TTFT, P95, GPU, infra, winback
   158→✅ 保持: 具体的性能数据 "3秒开服" "0.1%的概率"
   159→✅ 保持: 专业术语的英文表达，不要强行翻译成中文
   160→```
   161→
   162→**禁用防御性引号**:
   163→```
   164→❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"
   165→❌ 用引号免责: 这种所谓的"创新"...
   166→✅ 直接说清楚评价，不需要引号来暗示距离感；如果词本身不够精确，换个更准确的词，或用完整句子表达
   167→```
   168→
   169→**禁止连续复合长句**:
   170→```
   171→❌ 一段里全是逗号堆砌的长句，读者喘不过气
   172→✅ 短句抛出观点，长句解释逻辑，信息过载时用句号截断
   173→✅ 一句话里超过三个分句，考虑拆成两句
   174→```
   175→
   176→**段落长度**:
   177→- AI喜欢每段150-200字，整齐划一
   178→- 真人写作: 有的段落就一句话，有的可能300字，参差不齐
   179→
   180→**思维插入**:
   181→在段落间插入真实的思考过程:
   182→```
   183→[具体论述A]
   184→
   185→其实我知道大家可能会觉得这个想法太理想化。我也对此持有疑虑，必须承认这一点。
   186→
   187→但是...
   188→```
   189→
   190→**使用你的典型比喻**:
   191→- 巴别塔、西西弗斯、福特生产线、魔法
   192→- 服务器像宠物一样需要照顾
   193→
   194→### 2.4 情绪和态度层面
   195→
   196→**保持冷静客观，但加入细节**:
   197→```
   198→Before (AI味):
   199→这个技术方案经过验证是可行的，能够有效解决问题。
   200→
   201→After (去AI味):
   202→这个方案我们试了三个月，踩了不少坑，但确实能work。最关键的是，它能把P95延迟压到50ms以下，这对我们的场景够用了。
   203→```
   204→
   205→**必要时承认局限**:
   206→```
   207→✅ "说实话，这个问题我还没完全想清楚"
   208→✅ "我能力有限，只能做到这个程度"
   209→✅ "这是我们当前能做的最优解，不是完美解"
   210→```
   211→
   212→**使用你的金句模式**:
   213→- "其实我知道xxx，但我也对此持有非常疑虑的态度"
   214→- "我们可以从两个极端角度来看这个问题"
   215→- "这不仅是炫技，更是为了解决xxx的矛盾"
   216→
   217→---
   218→
   219→## 三、分步修订流程
   220→
   221→### Step 1: 快速扫描（2分钟）
   222→用查找功能搜索以下词汇，直接删除或替换:
   223→- "首先" "其次" "最后" "总之" "综上所述"
   224→- "不仅...而且" "既...又..."
   225→- "深入" "全面" "系统" "显著" "有效"
   226→- "让我们" "携手" "共创"
   227→- "赋能" "底层逻辑" "仪式性努力" "错失恐惧症" "精神枷锁"
   228→- "保守派/激进派" "向内求索/向外扩展"
   229→- "危机就是转机" "这是成长的机会" "最重要的选择"
   230→
   231→### Step 2: 结构检查（3分钟）
   232→- 标题是否过于工整？可以打乱一个
   233→- 每段字数是否太平均？制造一些参差感
   234→- 是否有"自问自答"的句子？改成直接陈述
   235→
   236→### Step 3: 句子重写（10分钟）
   237→- 找出最"AI味"的3-5个句子，用口语化方式重写
   238→- 检查技术术语是否保留英文
   239→- 加入1-2个比喻或具体案例
   240→
   241→### Step 4: 情绪注入（5分钟）
   242→- 找到1-2处可以表达"怀疑"或"自我修正"的地方，加入真实思考
   243→- 找到可以用"btw"或"说实话"的地方，增加口语化转折
   244→- 检查是否有过度自信的表达，适当降温
   245→
   246→### Step 5: 最后通读（3分钟）
   247→- 大声朗读，听起来是否像自己在说话
   248→- 是否还有"朗朗上口"的排比句？打破它
   249→- 是否有过于完美的结尾？改得实际一点
   250→
   251→---
   252→
   253→## 四、典型修订对照示例
   254→
   255→### 示例1: 技术方案介绍
   256→
   257→**Before (AI生成)**:
   258→```
   259→云计算作为新一代信息技术的重要组成部分，正在深刻改变着企业的IT架构。
   260→首先，云计算提供了弹性可扩展的计算资源；其次，它降低了企业的运维成本；
   261→最后，通过标准化的服务，云计算使得应用开发更加高效。因此，我们应当充分
   262→认识到云计算的战略意义，积极推进云原生技术的落地应用。
   263→```
   264→
   265→**After (去AI味)**:
   266→```
   267→云计算到底在干什么？说白了就是想建一个IT的巴别塔。
   268→
   269→让计算资源像水电一样随时可用，这是理想。但现实是，大部分企业用云就像
   270→租了个毛坯房，装修、搭建、运维，一堆活儿还得自己干。
   271→
   272→这就是为什么我们要做Lighthouse。它不是低配版CVM，而是一个"简装房"，
   273→开箱即用。btw，这背后其实是在赌一件事：牺牲部分灵活性，换取极致易用性，
   274→对大部分开发者来说是划算的。
   275→```
   276→
   277→### 示例2: 项目复盘
   278→
   279→**Before (AI生成)**:
   280→```
   281→本项目历时3个月，期间团队克服了诸多技术难题，最终成功上线。在此过程中，
   282→我们深刻认识到了充分沟通的重要性，同时也积累了宝贵的经验。展望未来，
   283→我们将继续优化产品性能，为用户提供更优质的服务体验。
   284→```
   285→
   286→**After (去AI味)**:
   287→```
   288→这个项目折腾了3个月才上线，中间踩的坑比预期多得多。
   289→
   290→最大的问题不是技术，是沟通。产品、研发、运维，三方对"稳定性"的定义
   291→完全不一样。后来我们干脆拉了个三方会，把SLA指标写在白板上，才算对齐。
   292→
   293→性能方面，P95延迟还是没压到目标值，但考虑到当前成本，已经是可接受的
   294→权衡了。下一步要做的是引入热迁移技术，这个能从根上解决问题，但需要
   295→底层VStation配合，不是短期能搞定的。
   296→
   297→这个项目让我最深的体会是：技术问题终究是人的问题。
   298→```
   299→
   300→### 示例3: 观点论述
   301→
   302→**Before (AI生成)**:
   303→```
   304→关于技术团队的管理，不同的组织有不同的做法。一方面，我们需要给予工程师
   305→充分的技术自由度；另一方面，也要建立必要的规范和流程。在实践中，我们
   306→应当在灵活性和规范性之间寻求平衡，这样才能既保证创新活力，又维护系统
   307→稳定。总的来说，管理是一门艺术，需要持续探索和优化。
   308→```
   309→
   310→**After (去AI味)**:
   311→```
   312→管理技术团队，我的核心原则是"对人编程"。
   313→
   314→程序员不是代码机器，他们有自己的底层逻辑。你要像理解API一样理解他们的
   315→反馈循环：给清晰的目标、足够的上下文、及时的反馈。
   316→
   317→至于"自由度"和"规范"的平衡？其实这是个伪命题。真正的职业工程师不需要
   318→你去平衡，他们自己就知道什么时候该严格遵守规范，什么时候可以突破。
   319→问题往往出在"学生思维"上——等着老师划重点，做完作业就万事大吉。
   320→
   321→这也是为什么我在团队强调"成人逻辑"：关注事情本身，而不是KPI表演。
   322→```
   323→
   324→---
   325→
   326→## 五、特殊情况处理
   327→
   328→### 5.1 如果文章是技术文档
   329→- 保持技术准确性优先
   330→- 删减"心灵鸡汤"式的铺垫
   331→- 保留列表和代码示例的工整
   332→- 但可以在前言和总结部分加入个人思考
   333→
   334→### 5.2 如果文章是团队汇报
   335→- 保留必要的正式感和完整性
   336→- 删减过度修饰，但保留数据和事实
   337→- 可以在"背景"部分加入坦诚的现状描述
   338→- 结尾从"展望未来"改为"下一步计划"
   339→
   340→### 5.3 如果文章是个人文章/博客
   341→- 可以更激进地去除AI痕迹
   342→- 增加更多思考过程
   343→- 使用更多比喻和隐喻
   344→- 敢于表达未完成的思考："这个问题我还在琢磨"
   345→
   346→---
   347→
   348→## 六、自检清单
   349→
   350→修订完成后，问自己以下问题:
   351→- [ ] 是否还有"首先...其次...最后"的结构？
   352→- [ ] 是否有过于工整的排比句？
   353→- [ ] 技术术语是否保留了英文？
   354→- [ ] 是否有至少1-2处自然口语（"btw" "其实"）？注意"说实话""说白了"是伪口语，不算
   355→- [ ] 段落长度是否有参差感？
   356→- [ ] 大声朗读时，是否听起来像你在说话而不是在背稿？
   357→- [ ] 是否删除了空洞的修饰词（"深入" "全面" "显著"）？
   358→- [ ] 结尾是否实际且可执行，而非"美好展望"？
   359→- [ ] "我"字是否泛滥？全文超过5个就要开始删
   360→- [ ] 是否有首尾呼应（同一个观点开头结尾各说一遍）？
   361→- [ ] 是否有宏大词汇轰炸（"不可逆的浪潮"、"范式转移"、"时代大背景"）？
   362→- [ ] 陈述事实时是否附带了主观评价，而不是纯客观罗列？
   363→- [ ] 是否使用了抽象黑话（如"赋能"、"底层逻辑"、"仪式性努力"等）？
   364→- [ ] 是否有强行分类的伪概念（如"保守派/激进派"、"向内求索/向外扩展"等）？
   365→- [ ] 是否有常识科普或爹味说教的内容？
   366→- [ ] 是否有鸡汤或情绪抚慰类的表达（如"危机就是转机"、"这是成长的机会"等）？
   367→
   368→---
   369→
   370→## 七、快速修订模板
   371→
   372→如果时间紧迫，使用以下最小修订清单:
   373→
   374→1. **批量替换**（30秒）:
   375→   - "首先" → 删除或改"第一个要说的是"
   376→   - "其次" → 删除或改"另外"
   377→   - "最后" → 删除或改"btw"
   378→   - "总而言之" → 删除整句
   379→   - "赋能" → 删除或改具体动作
   380→   - "底层逻辑" → 删除或改具体原因
   381→   - "仪式性努力" → 删除或改"花钱买心理安慰"
   382→   - "危机就是转机" → 删除或改具体困难和解决方法
   383→
   384→2. **挑3个最AI的句子重写**（3分钟）:
   385→   - 找排比句 → 改成一长一短
   386→   - 找空话 → 换成具体例子或数据
   387→   - 找过渡句 → 删除或改"说实话"
   388→
   389→3. **加比喻**（最后手段，不是常规操作）:
   390→   - 只有比喻真正比直说更清晰时才用，不要为了"有人味"强行加
   391→   - **永久禁用**："简装房"（仅限特定历史场景，不再泛用）
   392→   - 原则：全篇最多 1 个，没有也完全可以
   393→
   394→4. **改结尾**（1分钟）:
   395→   - 从"展望未来"改成"下一步要做X"
   396→   - 或直接说"这个事儿还没完全想清楚"
   397→
   398→---
   399→
   400→## 附录：典型词汇黑白名单
   401→
   402→### 黑名单（尽量避免）
   403→- 深入、全面、系统、显著、有效
   404→- 充分、积极、持续、不断、进一步
   405→- 切实、扎实、务实、落实
   406→- 携手、共创、共赢
   407→- 赋能、触达、闭环、抓手、底层逻辑、仪式性努力、错失恐惧症、精神枷锁
   408→- 不难看出、值得注意的是、需要强调的是
   409→- **宏大词汇类**：不可逆的浪潮、现实的巨浪、时代大背景、范式转移、深刻变革、历史性时刻
   410→- **伪分类类**：保守派/激进派、向内求索/向外扩展、左派/右派、传统派/革新派
   411→- **鸡汤类**：危机就是转机、这是成长的机会、最重要的选择、挑战与机遇并存
   412→
   413→### 白名单（鼓励使用）
   414→- 说实话、其实、btw
   415→- 这让我想到、我觉得
   416→- 问题是、关键在于
   417→- 说白了、坦白讲
   418→- 技术术语（CVM, Lighthouse, GPU, infra, etc.）
   419→- 具体数据（3秒、0.1%、P95）
   420→- 比喻（最后手段：只在比喻真正比直说更清晰时用；全篇最多 1 个，没有也可以）
   421→- **永久禁用**：简装房（仅限特定历史场景，不再使用）
   422→
   423→---
   424→
   425→**使用建议**:
   426→1. 首次修订，严格按流程走一遍（约30分钟）
   427→2. 熟练后，用"快速修订模板"（5分钟搞定）
   428→3. 定期积累好的改写案例，丰富个人表达库
   429→4. 如果AI生成的某段特别符合你的思路，可以保留，不必过度修改
   430→
   431→**终极目标**: 让读者读完后的感觉是"这绝对是Powell写的"，而不是"这看起来像AI生成的"。
   432→


     1→---
     2→description: Remove AI tone from article and save revised version
     3→argument-hint: <file_path>
     4→allowed-tools: Read, Write
     5→context: fork
     6→model: sonnet
     7→---
     8→
     9→# De-AI Article Reviser
    10→
    11→Remove artificial AI tone from articles and save the humanized version.
    12→
    13→## Step 1: Parse Input
    14→
    15→Input file path: $ARGUMENTS
    16→
    17→If no path provided, ask the user to provide a file path.
    18→
    19→## Step 2: Read Original Article
    20→
    21→Read the file content using the Read tool with the provided path.
    22→
    23→## Step 3: Analyze and Revise
    24→
    25→Analyze the article and rewrite it to remove AI characteristics:
    26→
    27→**AI characteristics to remove:**
    28→- Overly formal or robotic language
    29→- Repetitive sentence structures
    30→- Excessive use of transition words ("Moreover", "Furthermore", "Additionally")
    31→- Generic phrases ("It's worth noting that", "It's important to understand")
    32→- Lack of personal voice or authentic emotion
    33→- Over-explanation of obvious points
    34→- Artificial enthusiasm or politeness
    35→- Perfect grammar that lacks natural variation
    36→
    37→**Humanizing techniques:**
    38→- Use varied sentence lengths (mix short and long)
    39→- Include occasional contractions and colloquialisms
    40→- Add personal observations or subtle opinions
    41→- Use more specific, concrete examples
    42→- Embrace minor imperfections in structure
    43→- Add natural transitions and flow
    44→- Use active voice and direct language
    45→- Include rhetorical questions where appropriate
    46→
    47→**Important:**
    48→- Preserve the original meaning and key information
    49→- Maintain the same general structure and format
    50→- Keep any code blocks, lists, or formatting intact
    51→- Don't change technical terms or proper nouns
    52→- Preserve the original language (Chinese/English)
    53→
    54→## Step 4: Generate Revised Filename
    55→
    56→From the original file path, generate the revised filename:
    57→- Extract directory, filename, and extension
    58→- Add `-Revised` before the extension
    59→- Example: `/path/to/article.md` → `/path/to/article-Revised.md`
    60→
    61→## Step 5: Save Revised Version
    62→
    63→Write the humanized content to the new file path.
    64→
    65→## Step 6: Confirmation
    66→
    67→Output a success message showing:
    68→- Original file path
    69→- Revised file path
    70→- Brief summary of main changes made
    71→
    72→## Example Usage
    73→
    74→```
    75→/deai ~/Documents/my-article.md
    76→```
    77→
    78→```
    79→/deai ./blog/posts/2024-01-15-ai-trends.md
    80→```
    81→
    82→## Output Format
    83→
    84→```
    85→================================================================================
    86→✨ Article Revised - AI Tone Removed
    87→================================================================================
    88→
    89→📄 Original: /path/to/article.md
    90→💾 Revised:  /path/to/article-Revised.md
    91→
    92→🎯 Main Changes:
    93→- Simplified overly formal language
    94→- Varied sentence structures
    95→- Removed generic transition phrases
    96→- Added more natural flow
    97→
    98→✅ Done! Check the revised version.
    99→================================================================================
   100→```
   101→


/root/projects/butler/slack_bot/obsidian/__init__.py
/root/projects/butler/slack_bot/obsidian/cli.py
/root/projects/butler/slack_bot/obsidian/dispatcher.py
/root/projects/butler/slack_bot/obsidian/generators.py
/root/projects/butler/slack_bot/obsidian/indexer.py
/root/projects/butler/slack_bot/obsidian/embeddings.py
/root/projects/butler/slack_bot/obsidian/vector_store.py
/root/projects/butler/slack_bot/obsidian/note_ingester.py
/root/projects/butler/slack_bot/tools/health_write.py
/root/projects/butler/slack_bot/tools/obsidian.py


find /root/projects/butler -type f \( -name "*.md" -o -name "*.txt" \) -not -path "*/venv/*" -not -path "*/.pytest_cache/*" -not -path "*/.git/*" -not -path "*/tag20260215/*" -not -path "*/tag20260302/*" | xargs grep -l "生成\|写作\|prompt\|生成器\|generator\|deai\|去AI" 2>/dev/null | head -30

Find files containing generation-related keywords


find /root/projects/butler/slack_bot/obsidian -type f -name "*.py" -exec grep -l "prompt\|generator\|write\|style" {} \;

Find Python files in obsidian with relevant keywords


/root/projects/butler/BOT_FEATURES_REFERENCE.md
/root/projects/butler/BOT_FIX_SUMMARY.md
/root/projects/butler/docs/HEALTH_SYNC_README.md
/root/projects/butler/docs/QUICK_START_AFTER_RETURN.md
/root/projects/butler/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/docs/TESTING.md
/root/projects/butler/docs/TODO.md
/root/projects/butler/docs/gemini_root_cause_analysis.md
/root/projects/butler/docs/gmode_check_detailed.md
/root/projects/butler/docs/proxy_decision_guide.md
/root/projects/butler/docs/proxy_issue_final_analysis.md
/root/projects/butler/docs/safety_override_restored.md
/root/projects/butler/docs/ARCHITECTURE.md
/root/projects/butler/docs/TOOLS_REFERENCE.md
/root/projects/butler/experiments/CLEANUP_SUMMARY.md
/root/projects/butler/experiments/DIAGNOSIS_REPORT.md
/root/projects/butler/mannul-data-input.md
/root/projects/butler/README.md
/root/projects/butler/REPLY-SAMPLE.md
/root/projects/butler/SLACK_BOT_OPTIMIZATION.md
/root/projects/butler/writing_style.md
/root/projects/butler/zhihu-sample/12.md
/root/projects/butler/zhihu-style.md
/root/projects/butler/.claude/commands/deai.md
/root/projects/butler/Butler-Bot使用指南.md
/root/projects/butler/zhihu-bot-style.md
/root/projects/butler/zhihu-hunter-guide.md
/root/projects/butler/POWELL_REVISE.md


grep -r "MODE_NOTE\|zhihu\|obsidian\|generation\|写作" /root/projects/butler --include="*.md" --include="*.py" -l | grep -v venv | grep -v tag | head -20

Find files related to note mode and writing functionality


     1→# Butler Bot 使用指南 🤖
     2→
     3→欢迎使用 Butler，您的 **Bio-Hacker 级个人健康助手**。
     4→本指南将帮助您全面掌握 Bot 的各项能力，从基础记录到深度数据洞察。
     5→
     6→---
     7→
     8→## 1. 核心能力概览
     9→
    10→Butler 的核心逻辑是 **"Data First"**（数据驱动）。它不会凭空给出建议，而是基于您的真实生理数据（Garmin）和行为日志（手动记录）进行分析。
    11→
    12→| 模块 | 功能 | 典型场景 |
    13→| :--- | :--- | :--- |
    14→| **Garmin Sync** | 自动同步手表数据 | "昨天睡得怎么样？" |
    15→| **Manual Log** | 记录饮食、补剂、感受 | "记录摄入400mg甘氨酸镁" |
    16→| **Health Analyst** | 深度关联分析 | "镁片真的改善了我的深睡吗？" |
    17→| **Web Search** | 实时科学检索 | "查询最新的长寿研究" |
    18→| **Vision** | *多模态识别 (暂不可用)* | *拍照识别餐食热量* |
    19→
    20→---
    21→
    22→## 2. 工具与指令使用 (Tool Usage)
    23→
    24→Bot 内置了数十个 Function Calls，您只需用自然语言对话，无需记忆硬指令。
    25→
    26→### 🩺 数据记录 (Logging)
    27→*   **饮食**: "记录早餐：两个鸡蛋一杯咖啡" / "刚吃了一顿欺骗餐"
    28→*   **补剂**: "记录补充了 Vitamin D3 5000IU" / "Log supplement: Creatine 5g"
    29→*   **感受**: "感觉今天很不舒服，头痛，压力大" (Bot 会记录严重程度 1-10)
    30→*   **断食**: "开始 OMAD 断食模式" / "今天采用 16:8 断食"
    31→
    32→### 📊 数据查询 (Reading)
    33→*   **生理指标**: "我今天的静息心率是多少？" / "看看我这周的睡眠趋势"
    34→*   **历史回顾**: "上周我一共喝了几次酒？" / "查一下我最近的压力水平"
    35→
    36→### 🧠 深度分析 (Enhanced Analytics) **[NEW]**
    37→这是 Butler 最强大的 Bio-Hacking 功能，支持**因果分析**。
    38→
    39→*   **关联性 (Correlation)**:
    40→    *   *指令*: "分析饮酒对第二天睡眠的影响"
    41→    *   *原理*: 自动计算 `Alcohol Units(T)` 与 `Sleep Score(T+1)` 的相关系数。
    42→*   **分组对比 (Group Comparison)**:
    43→    *   *指令*: "比较我有吃镁片和没吃镁片日子的深睡时长"
    44→    *   *原理*: 将历史数据分为 `Has Magnesium` 和 `No Magnesium` 两组，进行 A/B Test。
    45→*   **图片识别**: 支持发送食物图片进行卡路里估算，或发送图表进行分析。
    46→    *   *注意*: 图片在发送给模型前会自动调整为最大 1024x1024 分辨率并进行压缩，以确保响应速度和稳定性。
    47→*   **健康建议**: 基于你的历史数据提供个性化建议。
    48→*   **趋势洞察 (Trends)**:
    49→    *   *指令*: "分析我过去90天的有氧适能趋势" (RHR vs Activity)
    50→
    51→---
    52→
    53→## 3. 联网搜索 (Web Search)
    54→
    55→Butler 集成了 DuckDuckGo 实时搜索。
    56→
    57→*   **什么时候自动触发？**
    58→    *   当您询问最新的科学研究（"Search for latest studies on NMN"）。
    59→    *   当您询问客观事实（"berberine side effects"）。
    60→    *   当需要验证某个健康理论时。
    61→*   **隐私说明**:
    62→    搜索内容仅限于关键词，**绝对不会**上传您的个人健康数据到搜索引擎。
    63→
    64→---
    65→
    66→## 4. 常见问题排查 (Troubleshooting)
    67→
    68→### 图片识别不可用 / Bot 无法看到图片
    69→如果您发送图片后 Bot 提示 "I cannot see the image" 或 "无法获取图片内容"，通常是因为 Slack App 缺少文件下载权限。
    70→
    71→**解决方法**:
    72→1. 进入 [Slack Apps Console](https://api.slack.com/apps).
    73→2. 选择您的 Bot 应用 -> 左侧菜单 **OAuth & Permissions**.
    74→3. 向下滚动到 **Bot Token Scopes**.
    75→4. 确保已添加 **`files:read`** 权限 (Authorization to read files).
    76→5. 滚动到顶部点击 **Reinstall to Workspace** 以应用更改.
    77→
    78→---
    79→
    80→## 5. 数据使用与隐私 (Data Privacy)
    81→
    82→Butler 是一个 **Local-First** 的设计。
    83→
    84→*   **存储位置**: 所有数据（JSON Logs, SQLite Cache）均存储在您本地的 `/data/health/` 目录下。
    85→*   **LLM 交互**:
    86→    *   Manual Logs 和 Garmin Data 会作为 Context 发送给 Gemini LLM 进行推理。
    87→    *   **敏感信息脱敏**: 代码中已对敏感字段（如精确 GPS）进行了过滤，仅发送统计级健康数据。
    88→*   **Obsidian 同步**:
    89→    *   Bot 每天会自动生成一篇 Markdown 格式的健康日报，同步到您的 Obsidian 库中，作为您的永久健康档案。
    90→
    91→---
    92→
    93→## 5. 提示词灵感 (Prompt Library)
    94→
    95→复制以下 Prompt，激发 Butler 的全部潜能：
    96→
    97→### 为了获得更好的分析：
    98→> "作为一名 Tech Executive，我最近感觉精力下降。请调取我过去 30 天的睡眠、压力和运动数据，结合我记录的饮食日志，帮我分析可能的原因。如果需要，可以对比工作日和周末的数据差异。"
    99→
   100→### 为了测试补剂效果：


     1→# 🤖 Butler - 智能个人助理系统
     2→
     3→> 一个企业级质量的模块化个人助理系统，专注于数据驱动的健康追踪、生物黑客实验和桌面自动化
     4→
     5→[![Python](https://img.shields.io/badge/Python-3.12-blue.svg)](https://www.python.org/)
     6→[![Code Quality](https://img.shields.io/badge/Code%20Quality-Enterprise-green.svg)](docs/REVIEW_AND_ROADMAP.md)
     7→[![Architecture](https://img.shields.io/badge/Architecture-⭐⭐⭐⭐⭐-yellow.svg)](docs/ARCHITECTURE.md)
     8→[![License](https://img.shields.io/badge/License-Private-red.svg)](LICENSE)
     9→
    10→---
    11→
    12→## 📋 目录
    13→
    14→- [项目概览](#-项目概览)
    15→- [核心特性](#-核心特性)
    16→- [设计原则](#-设计原则)
    17→- [架构设计](#-架构设计)
    18→- [技术栈](#-技术栈)
    19→- [快速开始](#-快速开始)
    20→- [模块详解](#-模块详解)
    21→- [使用指南](#-使用指南)
    22→- [开发规范](#-开发规范)
    23→- [性能指标](#-性能指标)
    24→- [未来规划](#-未来规划)
    25→- [贡献指南](#-贡献指南)
    26→
    27→---
    28→
    29→## 🎯 项目概览
    30→
    31→Butler 是一个为生物黑客和数据驱动决策者设计的**个人 AI 助理系统**。它将健康数据管理、智能分析和桌面自动化无缝集成，通过 Slack Bot 提供自然语言交互界面，让你可以像与私人助理对话一样管理个人数据。
    32→
    33→### 为什么选择 Butler?
    34→
    35→- 🏥 **全面的健康数据管理**: 自动同步 Garmin 设备数据，涵盖 14+ 种健康指标
    36→- 🤖 **智能 AI 助理**: 基于 Gemini 2.0 的 Slack Bot，支持自然语言查询和复杂工具调用
    37→- 📊 **高级数据分析**: Pandas 驱动的相关性分析、趋势预测和驱动因素识别
    38→- 🔒 **隐私优先**: 所有数据本地存储，无云依赖，完全掌控你的数据
    39→- 🛠 **高度可扩展**: 模块化架构，轻松添加新功能和数据源
    40→- 💻 **桌面自动化**: 持久化 Shell 会话，执行系统任务和脚本
    41→
    42→### 项目统计
    43→
    44→```
    45→核心代码:      ~10,600 行 Python
    46→模块数量:      3 个主要模块 (Health, Obsidian, Shell)
    47→工具数量:      14 个 AI 可调用工具
    48→健康指标:      14+ 种 (睡眠、心率、HRV、压力等)
    49→数据存储:      104 MB (SQLite + JSON)
    50→代码质量:      ⭐⭐⭐⭐⭐ (5/5)
    51→总体评分:      ⭐⭐⭐⭐☆ (4.1/5)
    52→```
    53→
    54→---
    55→
    56→## ✨ 核心特性
    57→
    58→### 1. 🏥 健康数据管理
    59→
    60→#### Garmin 自动同步
    61→- **增量同步**: 智能检测最后同步日期，只同步新数据
    62→- **批处理**: 历史数据回填，避免 API 限流
    63→- **14+ 健康指标**:
    64→  - 睡眠 (总睡眠、深睡、REM、睡眠评分)
    65→  - 心率 (静息心率、最大/最小/平均心率、心率区间)
    66→  - HRV (心率变异性、基线、状态)
    67→  - 压力 (平均/最大压力、时间分布)
    68→  - Body Battery (充电/消耗、最高/最低值)
    69→  - 步数、距离、卡路里、楼层
    70→  - 血氧饱和度 (SpO2)
    71→  - 呼吸率、水合作用
    72→  - 运动活动 (类型、时长、距离、心率、配速)
    73→
    74→#### 手动记录系统
    75→- **饮食日志**: 餐食类型、时间、描述、卡路里
    76→- **补剂追踪**: 名称、剂量、时间
    77→- **酒精记录**: 类型、数量、时间
    78→- **感受日志**: 症状类型、严重程度、描述
    79→- **禁食模式**: OMAD、PSMF 等饮食方案追踪
    80→
    81→#### 高级分析引擎
    82→```python
    83→# 相关性分析: 酒精对睡眠的影响
    84→analyze_driver(
    85→    driver_metric="alcohol_units",
    86→    target_metric="sleep_score",
    87→    method="correlation"
    88→)
    89→
    90→# 趋势分析: HRV 和静息心率趋势
    91→get_health_insights(
    92→    analysis_type="fitness_trends",
    93→    lookback_days=90
    94→)
    95→
    96→# 生活方式影响: 禁食对 Body Battery 的影响
    97→get_health_insights(
    98→    analysis_type="lifestyle_impact",
    99→    lookback_days=60
   100→)


/root/projects/butler/BOT_FEATURES_REFERENCE.md
/root/projects/butler/CONFIGURATION_SUMMARY.md
/root/projects/butler/docs/REVIEW_AND_ROADMAP.md
/root/projects/butler/docs/ARCHITECTURE.md
/root/projects/butler/docs/TOOLS_REFERENCE.md
/root/projects/butler/experiments/DIAGNOSIS_REPORT.md
/root/projects/butler/health/cli/obsidian.py
/root/projects/butler/health/services/obsidian.py
/root/projects/butler/list_samples.py
/root/projects/butler/README.md
/root/projects/butler/scripts/weekly_report.py
/root/projects/butler/scripts/bot_manager.py
/root/projects/butler/scripts/obsidian_bot.py
/root/projects/butler/scripts/obsidian_distiller.py
/root/projects/butler/scripts/obsidian_tool.py
/root/projects/butler/scripts/verify_obsidian_tools.py
/root/projects/butler/scripts/init_vault_indexer.py
/root/projects/butler/scripts/zhihu_debug_publish.py
/root/projects/butler/scripts/zhihu_e2e_test.py
/root/projects/butler/skills/obsidian_sync.py


ls -la /root/projects/butler | grep -E "\.md$"

List all markdown files in root directory


find /root/projects/butler -maxdepth 1 -name "*guide*" -o -maxdepth 1 -name "*prompt*" -o -maxdepth 1 -name "*style*" 2>/dev/null

Find guide, prompt, or style files in root


-rw-r--r--  1 root root   24803 Mar  2 10:58 BOT_FEATURES_REFERENCE.md
-rw-r--r--  1  501 games   2812 Feb  2 10:56 BOT_FIX_SUMMARY.md
-rw-r--r--  1  501 games   5114 Jan 22 11:30 Butler-Bot使用指南.md
-rw-r--r--  1  501 games   1236 Jan 19 13:35 CLAUDE.md
-rw-r--r--  1 root root    2950 Mar  2 10:57 CONFIGURATION_SUMMARY.md
-rw-r--r--  1  501 games   4596 Jan 19 14:04 decision.md
-rw-r--r--  1  501 games   6743 Jan 22 14:49 distilled_insights.md
-rw-r--r--  1  501 games   4188 Jan 19 13:46 health.md
-rw-r--r--  1  501 games   5361 Jan 20 14:49 mannul-data-input.md
-rw-r--r--  1 root root    3044 Mar  2 14:32 methodology.md
-rw-r--r--  1 root root   18310 Mar  6 09:31 POWELL_REVISE.md
-rw-r--r--  1 root root   32992 Mar  2 10:57 README.md
-rw-r--r--  1  501 games   3830 Jan 22 13:26 REPLY-SAMPLE.md
-rw-r--r--  1  501 games   5700 Jan 20 18:06 SLACK_BOT_OPTIMIZATION.md
-rw-r--r--  1 root root    3077 Mar  2 14:27 writing_style.md
-rw-r--r--  1 root root    6241 Mar  6 10:08 zhihu-bot-style.md
-rw-r--r--  1 root root    3008 Mar  4 11:14 zhihu-hunter-guide.md
-rw-r--r--  1 root root   16005 Mar  5 18:25 zhihu-style.md


/root/projects/butler/writing_style.md
/root/projects/butler/zhihu-style.md
/root/projects/butler/zhihu-bot-style.md
/root/projects/butler/zhihu-hunter-guide.md


Perfect! Now let me create a comprehensive summary of all the files I found:

## Summary of Writing Guides, Prompts, and Instructions for Obsidian Bot Content Generation

I've completed a thorough search of the Butler project. Here are all the markdown files related to writing guides, prompts, and instructions for content generation:

### **Core Writing Style & Generation Guides**

1. **`/root/projects/butler/zhihu-style.md`** (16,005 bytes)
   - Comprehensive Zhihu answer style guide with 10 sections
   - Covers core style positioning, writing principles, content organization, language features, content depth requirements, avoidance checklist, generation checklist, reference templates, and material sourcing
   - Includes detailed rules on tone, sentence structure, first-person usage, rhetorical devices, and specific prohibitions (AI tone, anxiety-mongering, false balance)
   - Contains 3 reference templates for different answer types (technical comparison, experience sharing, opinion commentary)

2. **`/root/projects/butler/zhihu-bot-style.md`** (6,241 bytes)
   - Additional constraints for Bot auto-generation scenarios (supplements zhihu-style.md)
   - Highest priority: pure text output (no Markdown symbols), direct terminology usage without parenthetical explanations
   - Strict prohibitions: no "谢邀", no self-promotion, no identity exposure, no poetry endings, no abstract jargon
   - Enforces sentence length variation (Burstiness) and allows fragmented syntax
   - Includes 6-item generation checklist

3. **`/root/projects/butler/writing_style.md`** (3,077 bytes)
   - Core writing DNA and communication principles
   - Emphasizes structured thinking with fragmented expression, technical idealism with restraint, authentic self-criticism, and calm fatalism
   - Bilingual accuracy (Chinese + English tech terms), conclusion-first approach, zero-fluff principle
   - Strict prohibitions on Markdown decoration, parenthetical explanations, and abstract jargon

4. **`/root/projects/butler/POWELL_REVISE.md`** (18,310 bytes)
   - Comprehensive "De-AI" article revision standard
   - 10 core writing principles (problem-driven opening, deletion priority, no recap, direct judgment, metaphor as last resort, hidden first-person, forced subjectivity, vocabulary reduction, audience baseline, no chicken soup)
   - Detailed AI trace identification checklist with 13 categories
   - Step-by-step revision operations manual with 4 levels (structure, sentence, emotion, formatting)
   - 3 detailed before/after examples (tech proposal, project retrospective, opinion piece)
   - 5-step revision workflow and quick revision template
   - Appendix with black/white vocabulary lists

### **Zhihu Hunter & Content Discovery**

5. **`/root/projects/butler/zhihu-hunter-guide.md`** (3,008 bytes)
   - Usage guide for Zhihu Hunter mode in Slack
   - 6 methods for finding questions: full auto-scan, directory-specific scan, single file, glob pattern matching, direct keywords, direct URL
   - Post-candidate operations: generate draft, regenerate with feedback, confirm publish
   - Draft generation notes: based on Obsidian knowledge base + recent web news, pure text output, no Markdown

### **De-AI Command Specification**

6. **`/root/projects/butler/.claude/commands/deai.md`** (101 lines)
   - Claude Code command specification for removing AI tone from articles
   - 6-step process: parse input, read original, analyze and revise, generate revised filename, save, confirm
   - Lists AI characteristics to remove (formal language, repetitive structures, excessive transitions, generic phrases, lack of voice, over-explanation, artificial enthusiasm, perfect grammar)
   - Humanizing techniques: varied sentence lengths, contractions, personal observations, specific examples, natural imperfections, active voice, rhetorical questions
   - Output format with success message template

### **Related Documentation**

7. **`/root/projects/butler/Butler-Bot使用指南.md`** (5,114 bytes)
   - User guide for Butler Bot with core capabilities overview
   - Includes prompt library section with example prompts for better analysis
   - Covers data logging, querying, and deep analysis features

8. **`/root/projects/butler/README.md`** (32,992 bytes)
   - Main project documentation
   - Includes core features, architecture, and usage guidelines
   - References Obsidian integration and content generation capabilities

### **Key Implementation Files (Python)**

9. **`/root/projects/butler/slack_bot/obsidian/

agentId: a7c76195a1aefaf68 (for resuming to continue this agent's work if needed)
<usage>total_tokens: 47233
tool_uses: 19
duration_ms: 283643</usage>

Prompt: Find all markdown files related to writing guides, prompts, or instructions for the Obsidian bot content generation. Look in directories like slack_bot/obsidian/, prompts/, guides/, or any other location that might contain writing style guides or article generation instructions. Search for files containing keywords like "写作", "style", "tone", "guide", "prompt", "template", "article", "生成", "deai", "去AI". Be thorough - check the entire project. Return the full paths and a brief summary of each file's content.


Good, I found the relevant files. Let me read the key writing guide files to understand their current content and provide advice on whether to modify existing ones or add a new step. The key files are:

1. `writing_style.md` - Core writing DNA
2. `zhihu-style.md` - Zhihu answer style guide
3. `zhihu-bot-style.md` - Bot auto-generation constraints
4. `POWELL_REVISE.md` - De-AI revision standard
5. `.claude/commands/deai.md` - De-AI command

Let me read the most relevant ones to understand the current pipeline.


找到了，你已经有一套相当完整的写作体系了。让我看看几个核心文件的内容。


# 写作风格指南 (Writing Style Guide)

## 1. 核心语感基因 (Style DNA)
*   **结构化思考，碎片化表达**：
    *   习惯使用清晰的列表（1, 2, 3...）和子弹点。
    *   即便是复杂论述，也要拆解为明确的标题（如“现状”、“挑战”、“结语”）。
*   **技术理想主义的浪漫**：
    *   可以使用宏大的历史或文学隐喻（如：西西弗斯、巴别塔、福特生产线、魔法），但每篇文章**最多出现 1-2 个比喻**，不重复使用同一个。
    *   将枯燥的技术概念”人格化”或”生活化”（如：服务器是宠物还是牛群）。
*   **真诚且透明的“自黑”**：
    *   不避讳谈及局限性或个人背景（“小镇做题家”）。以坦诚建立信任，反对官僚套话。
*   **冷静的宿命感与乐观**：
    *   语气中常带有“接受最坏情况，但坚持背水一战”的韧性。

## 2. 沟通与词汇 (Communication & Vocabulary)
*   **中英技术混排 (Bilingual Accuracy)**：
    *   在中文叙述中自然嵌入技术或商务术语（如：btw, todo, hosting, computing, infra, winback, poc, roadmap）。
    *   专业名词严格保留英文，追求表达的精确性。
*   **结论先行 & “为什么”驱动**：
    *   首先概述核心结论。
    *   强调行动的合理性，解释“为什么要解决这个问题”。
*   **零废话原则 (Zero Fluff)**：
    *   省略无意义的寒暄和重复。直接输出核心逻辑。

## 3. 输出规范 (Output Standards)
*   **简洁有序**：逻辑结构必须是第一位的，多用子弹点。
*   **去概念化**：擅长将复杂技术“人话化”。
*   **纯文本倾向**：优先用自然语言分段，不用 Markdown 加粗（**xxx**）装饰普通词汇，不用 `---` 分割线制造仪式感，标题和有序列表仅在结构真正需要时使用。
*   **减少解释**：尽量不要用括号来解释术语或者比喻，减少对流畅性的打断

## 4. 典型句式 (Patterns to Mimic)
*   “其实我知道大家觉得...但是我也对此持有非常疑虑的态度，我必须要明确承认这一点。”
*   “我们可以从两个极端角度来回答这些所有问题。”
*   “云的理想非常直接，就是我们要建设一个IT的巴别塔。”
*   “这不仅是炫技，更是为了解决...的矛盾。”

## 5. 禁忌 (Strict Don'ts)
*   **禁止**：说教式的语气（如”记得要注意...”）。
*   **禁止**：在没有具体方案时使用空洞的鼓励话语。
*   **禁止**：使用官僚色彩浓厚的行政套话。
*   **禁止**：在输出文本中提及内部决策框架名称（GPA、IPO 等）——这些是内部推理工具，直接按原则行事即可，不需要向读者点名。
*   **禁止**：在同一篇文章里重复使用同一个比喻；每篇文章比喻总量不超过 1-2 个，超出则删减。
*   **永久禁用比喻**：”简装房”——这是特定历史场景下的表达，不再在任何生成内容中使用。


# POWELL_REVISE.md
# AI味去除与文章修订规范

> **使用场景**: 当你与AI探讨并生成文章后，使用本规范对文章进行"去AI味"修订，使其更接近真实的个人表达。

---

## 修订原则总览

**核心理念**: 保持你的思想内核和逻辑骨架，去除AI生成痕迹，让文字更有"人味"。

**选定策略**:
- 语气强度: 保持原风格，仅去AI痕迹
- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
- 减少格式: 除了必要的分段，最好不要使用Markdown语法
- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外
- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用

---

## 零、七大写作原则（最高优先级）

在应用后续所有规则之前，先对齐这七条原则：

**1. 问题导入，禁止上帝视角**
开头必须从一个具体困惑、矛盾或场景切入。禁止以"X是Y的核心"、"在当今时代，Z越来越重要"这类全知叙述开场。

**2. 剃刀原则：删句优先于改句**
每一句话，问自己：删掉它，意思有没有损失？如果没有，直接删。不要改写冗余句，删除它。

**3. 戛然而止，禁止首尾呼应**
最后一句有实质信息量就停。不做总结，不回望全文。绝对禁止把开头的论点原样搬回结尾——同一个观点在首尾各说一遍是最典型的AI结构。

**4. 只说自己的判断，拒绝"理客中"**
禁止"有些人认为X，也有人认为Y"的防御性写法。直接说你认为什么。明确禁用"我可以理解他们的焦虑"、"当然，任何事物都有两面性"、"不可否认"——这类先共情再否定的套路是伪装成理性的逃避。

**5. 比喻是最后手段**
只有比喻真正比直说更清晰时才用，不要为了"有人味"而强行加。全篇最多1个，没有也完全可以。

**6. 隐去第一人称**
严禁泛滥使用"我"（"我一直有个观点"、"我在读源码时发现"、"我建议"）。观点和事实自己会说话，不要把"我"当成模拟人类语气的标点符号。偶尔一次没问题，全文每段都有就是问题。

**7. 强制主观判断**
陈述技术事实或描述某个工具/方案时，必须附带直接评价。不要只罗列特性，要说它暴力但有效、设计清爽、极度脆弱——这不是修辞，是信息密度的一部分。

**8. 词汇与概念降维**
绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）。禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念。

**9. 受众基线预设**
默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察。

**10. 封杀鸡汤与情绪抚慰**
禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话。

---

## 一、AI痕迹识别清单

### 1.1 必须删除的典型AI痕迹

**过度工整的过渡词**:
- ❌ "首先...其次...再次...最后..."
- ❌ "总而言之" "综上所述" "不难看出"
- ❌ "值得注意的是" "需要强调的是"
- ❌ "说白了" "说实话"
- ✅ 直接陈述，或用"btw" "其实" (仅在必要时使用)

**机械的排比和对仗**:
- ❌ "不仅...而且..." "既...又..." "一方面...另一方面..."
- ❌ 三个并列短句字数完全相等的排比
- ✅ 自然的递进，长短句交错，不刻意对称

**过度平衡的表达**:
- ❌ "虽然有A的优势，但也存在B的挑战，因此我们需要综合考虑..."
- ✅ 直接说你的判断: "A确实有价值，但B才是真正的瓶颈"

**防御性引用**:
- ❌ "有些人认为X，也有人认为Y，因此我们需要综合考虑"
- ❌ "不少专家指出..." "研究表明..."（用来代替自己表态）
- ✅ 直接说"我认为X" 或 "这件事我的判断是X"

**空洞的修饰词堆积**:
- ❌ "深入、全面、系统地" "显著提升" "有效解决"
- ✅ 用具体数据或比喻: "3秒开服" "像拆毛坯房和简装房的区别"

**AI喜欢的万能结尾**:
- ❌ "让我们携手共进，共创美好未来"
- ❌ "这不仅是挑战，更是机遇"
- ✅ 具体的下一步或诚实的不确定: "接下来我们要做X" 或 "说实话，这事儿我还没完全想清楚"

### 1.2 典型AI句式模式

**问题句式**:
- ❌ "那么，我们应该如何解决这个问题呢？" (AI喜欢自问自答)
- ✅ 直接给方案或坦承: "这个问题其实没有银弹" 或 "我的解决思路是..."

**完美的三段论 / 八股文骨架**:
- ❌ 提出问题(200字) → 分析问题(500字) → 解决问题(300字)
- ❌ "现象-本质-客观背景-解决方案"均分四段（最典型的AI骨架）
- ❌ "一、... 二、... 三、... 总结一句话：..." 这种汉字序号加强行收尾的结构，是八股文变体，全部禁用
- ❌ 任何形式的"总结一句话"/"一句话总结"/"综上"式收尾
- ✅ 可以先说结论，或者中间插入自己的怀疑和修正；说完最后一个有实质内容的点，直接停

**宏大词汇轰炸**:
- ❌ "不可逆的浪潮" "现实的巨浪" "范式转移" "时代大背景" "深刻变革"
- ❌ 连续多段都在描述宏大趋势而非具体现象
- ✅ 换成可被验证的具体描述："npm 依赖一更新就挂" "狂烧 Token"

---

## 二、修订操作手册

### 2.1 结构层面（保持，但微调）

**保持的部分**:
- ✅ 清晰的标题层级（1, 2, 3...）
- ✅ 子弹点列表
- ✅ "背景-现状-挑战-下一步"的逻辑框架

**需要微调的部分**:
- 在标题之间加入"过渡思考"，如: "btw，这让我想到一个更本质的问题..."
- 标题不需要完美对称，可以有长有短，有陈述也有反问
- 可以在正文段落中间插入用"---"分隔的独立思考片段

### 2.2 句子层面（重点修订区）

**删除过渡词堆积**:
```
Before (AI味):
首先，我们需要理解云计算的本质。其次，要认识到标准化的重要性。最后，我们才能真正实现IT巴别塔的愿景。

After (去AI味):
云计算的本质是什么？说白了就是标准化。只有把底层标准化了，才有可能建成IT巴别塔。
```

**打破排比和对仗**:
```
Before (AI味):
我们既要保证性能，又要控制成本，还要提升体验。

After (去AI味):
性能肯定要保证。但成本控制才是长期可持续的关键，用户体验是这两者平衡后的结果。
```

**增加口语化表达**:
```
Before (AI味):
经过深入分析，我们认为该方案具有可行性。

After (去AI味):
这个方案能不能行？我觉得问题不大，主要是看执行。
```

**保留技术准确性**:
```
✅ 保持: CVM, Lighthouse, TTFT, P95, GPU, infra, winback
✅ 保持: 具体的性能数据 "3秒开服" "0.1%的概率"
✅ 保持: 专业术语的英文表达，不要强行翻译成中文
```

**禁用防御性引号**:
```
❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"
❌ 用引号免责: 这种所谓的"创新"...
✅ 直接说清楚评价，不需要引号来暗示距离感；如果词本身不够精确，换个更准确的词，或用完整句子表达
```

**禁止连续复合长句**:
```
❌ 一段里全是逗号堆砌的长句，读者喘不过气
✅ 短句抛出观点，长句解释逻辑，信息过载时用句号截断
✅ 一句话里超过三个分句，考虑拆成两句
```

**段落长度**:
- AI喜欢每段150-200字，整齐划一
- 真人写作: 有的段落就一句话，有的可能300字，参差不齐

**思维插入**:
在段落间插入真实的思考过程:
```
[具体论述A]

其实我知道大家可能会觉得这个想法太理想化。我也对此持有疑虑，必须承认这一点。

但是...
```

**使用你的典型比喻**:
- 巴别塔、西西弗斯、福特生产线、魔法
- 服务器像宠物一样需要照顾

### 2.4 情绪和态度层面

**保持冷静客观，但加入细节**:
```
Before (AI味):
这个技术方案经过验证是可行的，能够有效解决问题。

After (去AI味):
这个方案我们试了三个月，踩了不少坑，但确实能work。最关键的是，它能把P95延迟压到50ms以下，这对我们的场景够用了。
```

**必要时承认局限**:
```
✅ "说实话，这个问题我还没完全想清楚"
✅ "我能力有限，只能做到这个程度"
✅ "这是我们当前能做的最优解，不是完美解"
```

**使用你的金句模式**:
- "其实我知道xxx，但我也对此持有非常疑虑的态度"
- "我们可以从两个极端角度来看这个问题"
- "这不仅是炫技，更是为了解决xxx的矛盾"

---

## 三、分步修订流程

### Step 1: 快速扫描（2分钟）
用查找功能搜索以下词汇，直接删除或替换:
- "首先" "其次" "最后" "总之" "综上所述"
- "不仅...而且" "既...又..."
- "深入" "全面" "系统" "显著" "有效"
- "让我们" "携手" "共创"
- "赋能" "底层逻辑" "仪式性努力" "错失恐惧症" "精神枷锁"
- "保守派/激进派" "向内求索/向外扩展"
- "危机就是转机" "这是成长的机会" "最重要的选择"

### Step 2: 结构检查（3分钟）
- 标题是否过于工整？可以打乱一个
- 每段字数是否太平均？制造一些参差感
- 是否有"自问自答"的句子？改成直接陈述

### Step 3: 句子重写（10分钟）
- 找出最"AI味"的3-5个句子，用口语化方式重写
- 检查技术术语是否保留英文
- 加入1-2个比喻或具体案例

### Step 4: 情绪注入（5分钟）
- 找到1-2处可以表达"怀疑"或"自我修正"的地方，加入真实思考
- 找到可以用"btw"或"说实话"的地方，增加口语化转折
- 检查是否有过度自信的表达，适当降温

### Step 5: 最后通读（3分钟）
- 大声朗读，听起来是否像自己在说话
- 是否还有"朗朗上口"的排比句？打破它
- 是否有过于完美的结尾？改得实际一点

---

## 四、典型修订对照示例

### 示例1: 技术方案介绍

**Before (AI生成)**:
```
云计算作为新一代信息技术的重要组成部分，正在深刻改变着企业的IT架构。
首先，云计算提供了弹性可扩展的计算资源；其次，它降低了企业的运维成本；
最后，通过标准化的服务，云计算使得应用开发更加高效。因此，我们应当充分
认识到云计算的战略意义，积极推进云原生技术的落地应用。
```

**After (去AI味)**:
```
云计算到底在干什么？说白了就是想建一个IT的巴别塔。

让计算资源像水电一样随时可用，这是理想。但现实是，大部分企业用云就像
租了个毛坯房，装修、搭建、运维，一堆活儿还得自己干。

这就是为什么我们要做Lighthouse。它不是低配版CVM，而是一个"简装房"，
开箱即用。btw，这背后其实是在赌一件事：牺牲部分灵活性，换取极致易用性，
对大部分开发者来说是划算的。
```

### 示例2: 项目复盘

**Before (AI生成)**:
```
本项目历时3个月，期间团队克服了诸多技术难题，最终成功上线。在此过程中，
我们深刻认识到了充分沟通的重要性，同时也积累了宝贵的经验。展望未来，
我们将继续优化产品性能，为用户提供更优质的服务体验。
```

**After (去AI味)**:
```
这个项目折腾了3个月才上线，中间踩的坑比预期多得多。

最大的问题不是技术，是沟通。产品、研发、运维，三方对"稳定性"的定义
完全不一样。后来我们干脆拉了个三方会，把SLA指标写在白板上，才算对齐。

性能方面，P95延迟还是没压到目标值，但考虑到当前成本，已经是可接受的
权衡了。下一步要做的是引入热迁移技术，这个能从根上解决问题，但需要
底层VStation配合，不是短期能搞定的。

这个项目让我最深的体会是：技术问题终究是人的问题。
```

### 示例3: 观点论述

**Before (AI生成)**:
```
关于技术团队的管理，不同的组织有不同的做法。一方面，我们需要给予工程师
充分的技术自由度；另一方面，也要建立必要的规范和流程。在实践中，我们
应当在灵活性和规范性之间寻求平衡，这样才能既保证创新活力，又维护系统
稳定。总的来说，管理是一门艺术，需要持续探索和优化。
```

**After (去AI味)**:
```
管理技术团队，我的核心原则是"对人编程"。

程序员不是代码机器，他们有自己的底层逻辑。你要像理解API一样理解他们的
反馈循环：给清晰的目标、足够的上下文、及时的反馈。

至于"自由度"和"规范"的平衡？其实这是个伪命题。真正的职业工程师不需要
你去平衡，他们自己就知道什么时候该严格遵守规范，什么时候可以突破。
问题往往出在"学生思维"上——等着老师划重点，做完作业就万事大吉。

这也是为什么我在团队强调"成人逻辑"：关注事情本身，而不是KPI表演。
```

---

## 五、特殊情况处理

### 5.1 如果文章是技术文档
- 保持技术准确性优先
- 删减"心灵鸡汤"式的铺垫
- 保留列表和代码示例的工整
- 但可以在前言和总结部分加入个人思考

### 5.2 如果文章是团队汇报
- 保留必要的正式感和完整性
- 删减过度修饰，但保留数据和事实
- 可以在"背景"部分加入坦诚的现状描述
- 结尾从"展望未来"改为"下一步计划"

### 5.3 如果文章是个人文章/博客
- 可以更激进地去除AI痕迹
- 增加更多思考过程
- 使用更多比喻和隐喻
- 敢于表达未完成的思考："这个问题我还在琢磨"

---

## 六、自检清单

修订完成后，问自己以下问题:
- [ ] 是否还有"首先...其次...最后"的结构？
- [ ] 是否有过于工整的排比句？
- [ ] 技术术语是否保留了英文？
- [ ] 是否有至少1-2处自然口语（"btw" "其实"）？注意"说实话""说白了"是伪口语，不算
- [ ] 段落长度是否有参差感？
- [ ] 大声朗读时，是否听起来像你在说话而不是在背稿？
- [ ] 是否删除了空洞的修饰词（"深入" "全面" "显著"）？
- [ ] 结尾是否实际且可执行，而非"美好展望"？
- [ ] "我"字是否泛滥？全文超过5个就要开始删
- [ ] 是否有首尾呼应（同一个观点开头结尾各说一遍）？
- [ ] 是否有宏大词汇轰炸（"不可逆的浪潮"、"范式转移"、"时代大背景"）？
- [ ] 陈述事实时是否附带了主观评价，而不是纯客观罗列？
- [ ] 是否使用了抽象黑话（如"赋能"、"底层逻辑"、"仪式性努力"等）？
- [ ] 是否有强行分类的伪概念（如"保守派/激进派"、"向内求索/向外扩展"等）？
- [ ] 是否有常识科普或爹味说教的内容？
- [ ] 是否有鸡汤或情绪抚慰类的表达（如"危机就是转机"、"这是成长的机会"等）？

---

## 七、快速修订模板

如果时间紧迫，使用以下最小修订清单:

1. **批量替换**（30秒）:
   - "首先" → 删除或改"第一个要说的是"
   - "其次" → 删除或改"另外"
   - "最后" → 删除或改"btw"
   - "总而言之" → 删除整句
   - "赋能" → 删除或改具体动作
   - "底层逻辑" → 删除或改具体原因
   - "仪式性努力" → 删除或改"花钱买心理安慰"
   - "危机就是转机" → 删除或改具体困难和解决方法

2. **挑3个最AI的句子重写**（3分钟）:
   - 找排比句 → 改成一长一短
   - 找空话 → 换成具体例子或数据
   - 找过渡句 → 删除或改"说实话"

3. **加比喻**（最后手段，不是常规操作）:
   - 只有比喻真正比直说更清晰时才用，不要为了"有人味"强行加
   - **永久禁用**："简装房"（仅限特定历史场景，不再泛用）
   - 原则：全篇最多 1 个，没有也完全可以

4. **改结尾**（1分钟）:
   - 从"展望未来"改成"下一步要做X"
   - 或直接说"这个事儿还没完全想清楚"

---

## 附录：典型词汇黑白名单

### 黑名单（尽量避免）
- 深入、全面、系统、显著、有效
- 充分、积极、持续、不断、进一步
- 切实、扎实、务实、落实
- 携手、共创、共赢
- 赋能、触达、闭环、抓手、底层逻辑、仪式性努力、错失恐惧症、精神枷锁
- 不难看出、值得注意的是、需要强调的是
- **宏大词汇类**：不可逆的浪潮、现实的巨浪、时代大背景、范式转移、深刻变革、历史性时刻
- **伪分类类**：保守派/激进派、向内求索/向外扩展、左派/右派、传统派/革新派
- **鸡汤类**：危机就是转机、这是成长的机会、最重要的选择、挑战与机遇并存

### 白名单（鼓励使用）
- 说实话、其实、btw
- 这让我想到、我觉得
- 问题是、关键在于
- 说白了、坦白讲
- 技术术语（CVM, Lighthouse, GPU, infra, etc.）
- 具体数据（3秒、0.1%、P95）
- 比喻（最后手段：只在比喻真正比直说更清晰时用；全篇最多 1 个，没有也可以）
- **永久禁用**：简装房（仅限特定历史场景，不再使用）

---

**使用建议**:
1. 首次修订，严格按流程走一遍（约30分钟）
2. 熟练后，用"快速修订模板"（5分钟搞定）
3. 定期积累好的改写案例，丰富个人表达库
4. 如果AI生成的某段特别符合你的思路，可以保留，不必过度修改

**终极目标**: 让读者读完后的感觉是"这绝对是Powell写的"，而不是"这看起来像AI生成的"。


---
description: Remove AI tone from article and save revised version
argument-hint: <file_path>
allowed-tools: Read, Write
context: fork
model: sonnet
---

# De-AI Article Reviser

Remove artificial AI tone from articles and save the humanized version.

## Step 1: Parse Input

Input file path: $ARGUMENTS

If no path provided, ask the user to provide a file path.

## Step 2: Read Original Article

Read the file content using the Read tool with the provided path.

## Step 3: Analyze and Revise

Analyze the article and rewrite it to remove AI characteristics:

**AI characteristics to remove:**
- Overly formal or robotic language
- Repetitive sentence structures
- Excessive use of transition words ("Moreover", "Furthermore", "Additionally")
- Generic phrases ("It's worth noting that", "It's important to understand")
- Lack of personal voice or authentic emotion
- Over-explanation of obvious points
- Artificial enthusiasm or politeness
- Perfect grammar that lacks natural variation

**Humanizing techniques:**
- Use varied sentence lengths (mix short and long)
- Include occasional contractions and colloquialisms
- Add personal observations or subtle opinions
- Use more specific, concrete examples
- Embrace minor imperfections in structure
- Add natural transitions and flow
- Use active voice and direct language
- Include rhetorical questions where appropriate

**Important:**
- Preserve the original meaning and key information
- Maintain the same general structure and format
- Keep any code blocks, lists, or formatting intact
- Don't change technical terms or proper nouns
- Preserve the original language (Chinese/English)

## Step 4: Generate Revised Filename

From the original file path, generate the revised filename:
- Extract directory, filename, and extension
- Add `-Revised` before the extension
- Example: `/path/to/article.md` → `/path/to/article-Revised.md`

## Step 5: Save Revised Version

Write the humanized content to the new file path.

## Step 6: Confirmation

Output a success message showing:
- Original file path
- Revised file path
- Brief summary of main changes made

## Example Usage

```
/deai ~/Documents/my-article.md
```

```
/deai ./blog/posts/2024-01-15-ai-trends.md
```

## Output Format

```
================================================================================
✨ Article Revised - AI Tone Removed
================================================================================

📄 Original: /path/to/article.md
💾 Revised:  /path/to/article-Revised.md

🎯 Main Changes:
- Simplified overly formal language
- Varied sentence structures
- Removed generic transition phrases
- Added more natural flow

✅ Done! Check the revised version.
================================================================================
```


Now I have a clear picture of the user's writing guide ecosystem:

1. **`writing_style.md`** - Core style DNA (language gene guide)
2. **`POWELL_REVISE.md`** - Post-generation de-AI revision standard (very comprehensive)
3. **`.claude/commands/deai.md`** - The Claude Code command that executes the de-AI process

The user's question is: should they modify existing guide documents, or add a new step?

Looking at the text the user showed me earlier, the issues I identified are already well-covered by the existing guides:

1. **Metaphor overuse** → `writing_style.md` line 8 already says "每篇文章最多出现 1-2 个比喻" and `POWELL_REVISE.md` principle 5 says "比喻是最后手段"

2. **Dramatic adjectives** → `POWELL_REVISE.md` has "空洞的修饰词堆积" section
3. **Buzzwords/big concepts** → `POWELL_REVISE.md` principle 8 "词汇与概念降维"
4. **Chicken soup endings** → `POWELL_REVISE.md` principle 10 "封杀鸡汤与情绪抚慰" and principle 3 "戛然而止"
5. **Inconsistent tone** → Not explicitly covered

The real problem isn't missing rules—it's that the guides exist but aren't being applied consistently during the revision process.

Looking at the workflow, the bot generates content using writing_style.md, then the /deai command applies POWELL_REVISE.md, but the /deai command itself seems quite generic and might not be properly leveraging those revision principles. The issue could be in how the generation prompt references these guides, whether the revision command actually uses POWELL_REVISE.md effectively, or simply that the LLM isn't adhering to them strongly enough. I'm realizing the `/deai` command is the real bottleneck here—it's using oversimplified rules instead of actually pulling from the detailed `POWELL_REVISE.md` guide that already exists. Rather than creating new documents, I should focus on making sure that command and the generation pipeline are actually referencing the comprehensive style guides already in place.


让我再看看 Obsidian bot 的生成端是怎么用这些 guide 的。