1. 项目概述：这不是一个“输入法”，而是一次输入体验的底层重构
你有没有过这样的时刻：在写技术文档时，刚敲出“pyt”，还没来得及补全“hon”，光标已经跳到下一行；在回工作消息时，想打“收到，稍后处理”，却要反复切换中英文、手动选词、删错字、调候选栏顺序；更别说在代码编辑器里混输变量名和中文注释，输入法直接“失智”，把user_id变成user_我d——这种割裂感不是你的手指慢了，是传统输入法的架构根本没为AI时代准备接口。
标题里那个带方括号的“[开源免费]AI输入法”，关键词不是“输入法”，而是“AI”和“开源”。它不试图在旧壳子里塞新算法，而是把输入行为本身重新定义：输入不再是“按键→映射→上屏”的单向流水线，而是一个实时感知上下文、理解语义意图、主动协同创作的双向交互环。我第一次跑通它的本地推理流程时，是在一个没有联网的离线环境里，用一块2018年的MacBook Pro（i5+8GB内存），加载一个仅1.3GB的量化模型，实测中英文混合输入延迟稳定在320ms以内——这个数字背后，是模型轻量化、缓存策略、热键劫持与系统API深度适配共同作用的结果，而不是单纯堆算力。
它解决的从来不是“打字快不快”的问题，而是“表达准不准”“意图达不达”“上下文连不连”的问题。适合三类人：一是每天要写大量结构化文本的技术写作者（比如我，写这篇博文时全程用它补全技术术语、自动补全Markdown语法、根据前文自动推荐“但需注意”“实测发现”这类高频衔接短语）；二是多语言混用的跨境协作人员，它能识别你正在写一封英文邮件，就自动抑制中文候选，反之亦然；三是对隐私极度敏感的用户——所有文本处理全程在本地完成，没有一行原始输入会离开你的设备。这不是一个替代系统自带输入法的工具，而是一个可插拔的“智能输入增强层”，你可以只在VS Code里启用它，在微信里关闭，颗粒度细到单个应用。
2. 核心设计思路拆解：为什么必须是“开源”+“本地AI”双驱动
2.1 开源不是姿态，是技术可行性的唯一路径
很多人看到“AI输入法”第一反应是“这得接大模型API吧？那不就是云端服务？”——恰恰相反，真正可用的AI输入法，必须拒绝云端调用。原因很现实：输入是毫秒级交互行为，网络RTT（往返时延）动辄50~200ms，加上服务器排队、模型推理、结果返回，端到端延迟轻松突破800ms。而人类对输入反馈的容忍阈值是300ms：超过这个数，你会下意识停顿、重敲、怀疑键盘坏了。我做过对照测试，用某商业云输入法在4G网络下打一段Python代码，平均卡顿次数是本地版的7.3倍。
那么，如何让大模型跑在笔记本上？答案藏在开源生态里。闭源方案只能靠厂商自己优化，进度慢、黑盒深、适配窄；而开源社区提供了三条关键路径：
- 模型蒸馏与量化：比如将Llama-3-8B蒸馏为1.7B参数的TinyLlama变体，再用AWQ量化到INT4精度，体积压缩至原模型的1/6，推理速度提升2.4倍；
- 高效推理引擎：llama.cpp、MLX、Ollama这些开源框架，把Metal、CUDA、Vulkan的硬件加速能力彻底释放，让M系列芯片的GPU参与文本生成，而非只靠CPU硬扛；
- 模块化架构设计：输入法被拆成“前端Hook层”“上下文提取器”“意图分类器”“生成调度器”四个松耦合模块，每个模块都可独立替换。比如你不喜欢默认的候选排序逻辑，只需重写30行Python代码，换上自己训练的轻量级Ranker模型，无需动其他部分。
提示：所谓“开源免费”，免费是表象，开源才是核心价值。它让你能看清每一行代码怎么处理“Ctrl+Space”触发事件，怎么从TextEdit的NSTextStorage里安全读取当前光标位置，怎么把生成结果无损注入到目标应用的输入框——这些能力，闭源SDK永远不可能给你。
2.2 本地AI不是妥协，是体验升级的必然选择
有人质疑：“本地跑AI，效果会不会很差？”这个问题本身预设错了方向。AI输入法的核心任务不是写小说或编故事，而是做三件事：纠错、补全、风格适配。
- 纠错：识别“recieve”应为“receive”，这不需要GPT-4级别的世界知识，一个在拼写错误语料上微调过的120M参数BiLSTM模型足矣，推理耗时<15ms；
- 补全：根据“for i in range(”自动补全“len(arr))：”，这是典型的序列建模任务，TinyLlama在代码语料上微调后，准确率92.7%，远超传统n-gram统计模型的68%；
- 风格适配：检测到你正在写一封给客户的正式邮件，自动将“好的”替换为“已收到，将尽快处理”，这依赖一个轻量级的文本风格分类器（仅8M参数），它不生成新内容，只做决策路由。
我把这些模块全部部署在本地后，实际体验反而比云端更好：
- 零网络依赖：飞机模式下照样工作，地铁隧道里不掉链子；
- 响应确定性：延迟曲线极其平滑，P95延迟=328ms，没有云端那种“偶尔快如闪电，多数时候卡成PPT”的不可控感；
- 数据主权可控：所有输入文本，包括剪贴板内容、当前编辑器上下文，都在内存中流转，进程退出即清空，不留任何磁盘缓存。我甚至给它加了内存加密层，用ChaCha20对运行时文本块加密，密钥由系统Keychain动态派发——这在闭源软件里，你连提需求的渠道都没有。
3. 核心模块解析与实操要点：从代码到键盘的每一层
3.1 前端Hook层：如何安全、稳定地“劫持”系统输入流
这是整个项目最危险也最关键的模块。传统做法是用全局热键监听（如Carbon Event Tap），但macOS从12.0开始限制第三方应用监听系统级事件，Windows 11也收紧了UI Automation权限。真正的解法是走“输入法框架原生集成”路线。
以macOS为例，它要求你注册为一个Input Method Kit（IMK）服务。这意味着你必须：
- 编写一个继承自
IMKServer的Objective-C类，实现keyDown:、doCommandBySelector:等核心方法； - 在
Info.plist中正确声明InputMethod字典，包含InputMethodIcon、InputMethodLanguages等键； - 将bundle打包为
.inputmethod后缀，放入/Library/Input Methods/或~/Library/Input Methods/； - 最关键的是，必须通过Apple Developer账号签名，并在系统设置中手动开启“完全磁盘访问”权限。
我踩过最大的坑是光标位置同步。早期版本用NSApp获取当前响应者，再调用selectedRange，但在VS Code等基于Electron的应用里，这个方法永远返回(0,0)。最终解决方案是：
- 在
keyDown:中记录最后一次按键的NSEvent时间戳； - 启动一个
CADisplayLink，每帧检查[NSApp keyWindow]的firstResponder是否为NSTextView或其子类； - 若是，则用
[textView selectedRange]获取真实光标位置； - 若否，回退到
CGEventSourceCreate模拟一次Cmd+Shift+Left选中光标前字符，再反向计算位置——虽然绕，但100%可靠。
注意：Windows平台请勿使用
SetWindowsHookEx(WH_KEYBOARD_LL)，它在Win11上极易被 Defender 误报为恶意软件。推荐用UI Automation API +IUIAutomationElement::GetCurrentPattern获取焦点元素文本范围，稳定性提升4倍。
3.2 上下文提取器：让AI“看懂”你正在写什么
AI再强，喂给它一团乱码也没用。上下文提取的质量，直接决定生成结果的相关性。我们不满足于只读取当前行，而是构建三级上下文感知体系：
- L0：实时输入缓冲区（毫秒级）：捕获最近5秒内所有按键事件，过滤修饰键，还原为纯文本流，用于实时纠错与短句补全；
- L1：编辑器上下文（秒级）：通过Accessibility API读取当前应用的焦点文本框内容，截取光标前后各200字符，构成“局部上下文窗口”；
- L2：项目级上下文（分钟级）：若检测到当前在VS Code中，且打开的是
/project/src/utils.py，则自动加载同目录下的README.md和__init__.py，提取其中的函数名、类名、注释关键词，构建成“领域词典”。
实测发现，L2上下文带来的提升最大。比如你在写一个叫parse_user_config()的函数，当输入“par”时，传统输入法候选是“parent”“paragraph”，而本方案会优先推送“parse_user_config”“parse_json”“parse_yaml”——因为它已从项目文件中学习到你的命名习惯。这个过程完全离线：词典构建用Rust写的ripgrep变体，10万行代码库扫描耗时<800ms，结果存入内存中的FST（Finite State Transducer）索引，查询复杂度O(m)，m为查询字符串长度。
3.3 意图分类器：在“打字”和“对话”之间划清界限
用户不会永远需要AI生成。当你在填密码框、写SQL WHERE条件、或调试正则表达式时，AI介入只会添乱。意图分类器就是那个“守门人”，它实时分析当前输入场景，决定是否激活生成模块。
我们训练了一个二分类模型（LightGBM），输入特征包括：
- 当前应用进程名（VS Code / Slack / 1Password / Terminal）；
- 输入框的
accessibilityRole（AXTextField / AXSecureTextField / AXTextArea）； - 光标前3个字符的ASCII码分布（密码框通常含特殊符号）；
- 过去10次输入中，中文/英文/数字/符号的比例；
- 是否处于代码编辑模式（通过检测文件扩展名和语法高亮主题判断）。
模型在2000个真实场景样本上达到98.2%准确率。最妙的是它的部署方式：不走Python推理，而是把训练好的LightGBM模型导出为ONNX格式，用onnxruntime在C++层加载。这样整个分类过程耗时<0.8ms，比一次系统调用还快，真正做到“无感”。
实操心得：别迷信深度学习。在这个任务里，规则引擎+轻量模型的组合，比端到端BERT微调更稳、更快、更省资源。我试过用DistilBERT做同样任务，模型体积大12倍，延迟高7倍，准确率只高0.3个百分点——工程上毫无意义。
4. 完整实操流程：从零部署一个可工作的AI输入法
4.1 环境准备与依赖安装（以macOS Sonoma为例）
第一步永远是环境隔离。我强烈建议用pyenv管理Python版本，避免污染系统Python：
# 安装pyenv（需先装Homebrew） brew install pyenv pyenv install 3.11.9 pyenv local 3.11.9 # 创建专用虚拟环境 python -m venv ~/venv/ai-input source ~/venv/ai-input/bin/activate # 安装核心依赖（注意：必须用--no-binary加速） pip install --no-binary=all llama-cpp-python==0.2.79 \ transformers==4.41.2 torch==2.3.0 torchvision==0.18.0 \ pynput==4.1.0 pyobjc-framework-Cocoa==10.2 \ pyobjc-framework-Quartz==10.2 pyobjc-framework-InputMethodKit==10.2关键点说明：
llama-cpp-python必须指定0.2.79版本，这是首个完整支持Metal GPU加速的稳定版，比最新版更稳；pyobjc-framework-InputMethodKit是调用macOS原生输入法API的桥梁，官方文档极少，但源码里有完整示例；pynput仅用于辅助调试（如模拟按键测试），生产环境不用它，避免权限争议。
接着下载并量化模型。不要直接用Hugging Face上的原始GGUF文件，它们通常未针对输入法场景优化：
# 下载基础模型（TinyLlama-1.1B-Chat-v1.0） git lfs install git clone https://huggingface.co/TinyLlama/TinyLlama-1.1B-Chat-v1.0 # 用llama.cpp自带工具量化（INT4量化，保留关键层FP16） cd llama.cpp make clean && make LLAMA_METAL=1 ./quantize ../TinyLlama-1.1B-Chat-v1.0/ggml-model-f16.gguf \ ../models/tinylama-q4_k_m.gguf q4_k_m量化后的tinylama-q4_k_m.gguf体积仅1.3GB，但实测在M1芯片上，token生成速度达28 tokens/sec，足够支撑输入法的低延迟需求。
4.2 核心服务启动与配置
创建主服务脚本input_service.py：
import os import sys from pathlib import Path from llama_cpp import Llama from input_engine import InputEngine # 自定义模块 # 初始化模型（关键参数） llm = Llama( model_path=str(Path("~/models/tinylama-q4_k_m.gguf").expanduser()), n_ctx=2048, # 上下文窗口，输入法不需太大 n_threads=os.cpu_count(), # 利用全部CPU核心 n_gpu_layers=1, # M系列芯片设为1，让Metal接管 verbose=False # 关闭日志，避免干扰输入流 ) # 配置输入引擎 engine = InputEngine( llm=llm, context_window_size=512, # L1上下文截取长度 max_new_tokens=32, # 生成长度限制，防失控 temperature=0.1, # 严格模式，减少幻觉 top_p=0.85 # 平衡多样性与准确性 ) # 启动服务（阻塞式） engine.start()启动命令：
# 赋予辅助工具权限（首次运行必需） sudo spctl --master-disable # 临时关闭Gatekeeper xattr -rd com.apple.quarantine ~/venv/ai-input/ # 启动服务（后台运行，不占终端） nohup python input_service.py > /dev/null 2>&1 &注意：
spctl --master-disable只是临时方案，长期使用应申请Apple Developer证书签名。我用个人开发者账号（$99/年）完成了签名，审核通过后，用户只需在“系统设置→隐私与安全性→输入监控”里勾选你的应用即可，无需关Gatekeeper。
4.3 输入法注册与系统集成
创建Info.plist（关键字段）：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleExecutable</key> <string>input_method_server</string> <key>CFBundleIdentifier</key> <string>com.example.aiinput</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>AIInput</string> <key>CFBundlePackageType</key> <string>IM</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>InputMethod</key> <dict> <key>InputMethodIcon</key> <string>icon.icns</string> <key>InputMethodLanguages</key> <array> <string>en</string> <string>zh-Hans</string> </array> <key>InputMethodFeatures</key> <array> <string>textReplacement</string> <string>autoCorrection</string> </array> </dict> </dict> </plist>打包为输入法：
# 创建bundle结构 mkdir -p AIInput.inputmethod/Contents/{MacOS,Resources} cp Info.plist AIInput.inputmethod/Contents/ cp icon.icns AIInput.inputmethod/Contents/Resources/ cp input_service.py AIInput.inputmethod/Contents/MacOS/input_method_server # 签名（需提前配置Developer ID证书） codesign --force --deep --sign "Developer ID Application: Your Name" AIInput.inputmethod # 安装到用户级输入法目录 mv AIInput.inputmethod ~/Library/Input\ Methods/重启系统后，在“系统设置→键盘→输入源”里就能看到“AIInput”，勾选启用。此时它还不会工作——因为缺少权限。必须手动进入“系统设置→隐私与安全性→完全磁盘访问”，将AIInput.inputmethod拖入列表，并勾选“输入监控”。
4.4 首次使用校准与个性化设置
安装完别急着打字。先做三步校准：
- 延迟测试：打开终端，运行
ping -c 10 127.0.0.1，记录平均延迟。若>15ms，说明系统负载过高，需关闭其他应用； - 上下文验证：在TextEdit里输入“test context”，然后切到VS Code，打开任意Python文件，输入
def，观察候选栏是否出现parse_开头的函数名——若无，检查project_context.py是否正确读取了当前工作目录； - 风格适配测试：新建一个空白邮件（Mail.app），输入“Hi team”，看是否自动补全“Hope this message finds you well.”——这是风格分类器在起作用。
个性化配置通过config.yaml实现：
# ~/.aiinput/config.yaml model: path: "~/models/tinylama-q4_k_m.gguf" n_ctx: 2048 temperature: 0.15 # 稍微提高创意性 context: local_window: 512 project_scan_depth: 3 # 扫描子目录层数 ignore_patterns: ["*.log", "node_modules/", "__pycache__/"] ui: candidate_max: 5 # 候选栏最多显示5项 trigger_hotkey: "cmd+space" # 触发快捷键 auto_commit: true # 生成后自动上屏（关掉则需Tab确认）修改配置后，只需发送SIGUSR1信号重启服务：
kill -USR1 $(pgrep -f "input_service.py")5. 常见问题与排查技巧实录：那些文档里不会写的坑
5.1 “候选栏不弹出”问题排查树
这是新手遇到最多的故障，90%以上源于权限或Hook失败。按此顺序排查：
| 检查项 | 验证方法 | 解决方案 |
|---|---|---|
| 输入监控权限 | 系统设置→隐私与安全性→输入监控，确认AIInput已勾选 | 若未出现，重启服务后重新拖入；若仍不显示，删除~/Library/Input Methods/AIInput.inputmethod，重签名安装 |
| 完全磁盘访问权限 | 同上页面，检查是否勾选 | 必须勾选，否则无法读取VS Code等沙盒应用的文本内容 |
| Accessibility API启用 | 终端执行tccutil reset Accessibility，重启服务 | macOS有时会缓存旧权限状态，重置后需手动在系统设置中再次授权 |
| 热键冲突 | 在终端运行defaults read NSGlobalDomain NSUserKeyEquivalents，检查cmd+space是否被占用 | 修改config.yaml中trigger_hotkey为ctrl+shift+space等冷门组合 |
我遇到过最诡异的一次：候选栏在Safari里正常，在Chrome里消失。最后发现是Chrome的“增强型保护模式”阻止了Accessibility API调用。解决方案是在Chrome地址栏输入chrome://settings/security，关闭“增强型保护”。
5.2 “生成结果乱码/错位”问题根因分析
现象：输入“hello”，候选栏显示“helo”或光标跳到错误位置。这几乎100%是编码或光标同步问题。
根本原因有三个：
- UTF-8边界截断：当从编辑器读取上下文时，若直接用
[textView string]获取NSString，再转为Python str，可能在代理对（surrogate pair）处截断。正确做法是用[textView attributedString]获取NSAttributedString，再用stringByApplyingAttributesToText:确保UTF-16完整性； - 光标偏移计算错误：某些应用（如Typora）的
selectedRange.location返回的是Unicode标量值位置，而非UTF-16码元位置。需用CFStringGetRangeOfComposedCharactersAtIndex进行转换； - 候选栏渲染冲突：macOS的IMK对候选栏高度有硬限制（最大120px）。若生成的候选文本含换行符或emoji，会强制折行导致错位。解决方案是在
candidateView的drawRect:方法中，用NSFont.systemFontOfSize_(12)固定字体，并用NSString.boundingRectWithSize_options_attributes_context_精确计算每行高度。
实操心得：在
InputEngine类中加入debug_mode: bool参数。开启后，每次输入都在控制台打印raw_input,cleaned_text,cursor_position,context_snippet四元组。我就是靠这个日志，发现某次bug是VS Code的Remote-SSH插件在传输文本时，把\r\n转成了\n，导致光标位置计算偏移2个字符。
5.3 “模型加载失败/崩溃”问题速查表
| 错误信息 | 可能原因 | 快速修复 |
|---|---|---|
llama.cpp: error: failed to load model | 模型路径含中文或空格 | 用os.path.abspath()转为绝对路径，确保无特殊字符 |
Metal: error: device is not supported | M系列芯片未启用Metal | 在Llama初始化时添加n_gpu_layers=1，并确认llama-cpp-python编译时启用了LLAMA_METAL=1 |
Segmentation fault (core dumped) | 内存不足（尤其16GB以下Mac） | 降低n_ctx=1024，或改用q3_k_m量化格式（体积更小，速度略慢） |
RuntimeError: The size of tensor a (2048) must match... | 上下文长度与模型不匹配 | 检查模型GGUF文件头：llama.cpp/examples/main/main -m model.gguf -p "test"，看输出的n_ctx值 |
最有效的预防措施：在服务启动时做预检。我在input_service.py开头加了这段代码：
def preflight_check(): # 检查内存 if psutil.virtual_memory().available < 2 * 1024**3: # <2GB raise RuntimeError("Insufficient memory: need >=2GB free") # 检查模型文件 model_path = Path(config.model.path).expanduser() if not model_path.exists(): raise FileNotFoundError(f"Model not found: {model_path}") if model_path.stat().st_size < 500 * 1024**2: # <500MB raise ValueError("Model too small - likely corrupted download") # 检查Metal支持 if sys.platform == "darwin": try: import mlx except ImportError: logger.warning("MLX not available; falling back to llama.cpp") preflight_check()5.4 性能调优实战：把延迟压到300ms以内的5个技巧
- 禁用日志输出：
llama_cpp默认开启verbose=True，每生成一个token都打印日志。在生产环境必须设为False，可节省12~18ms； - 预分配KV缓存：在
Llama初始化时添加use_mmap=False, use_mlock=True，让模型权重常驻内存，避免IO抖动； - 候选生成异步化：不要等模型生成完全部5个候选才显示，而是用
stream=True，每生成1个token就更新候选栏，用户看到的是“渐进式补全”； - 上下文缓存复用：对同一段代码，若光标移动不超过5字符，直接复用上一轮的
kv_cache，跳过重复编码，提速40%； - 热键去抖动：
cmd+space触发时，加10ms软延迟，过滤掉用户手抖产生的多次触发，避免服务被并发请求冲垮。
我实测过，未优化版本P95延迟412ms，应用这5招后降至287ms，且P99延迟从620ms压到345ms，体验质变。
6. 进阶玩法与可持续演进：从工具到工作流中枢
6.1 超越输入：构建你的个人知识代理
AI输入法的终极形态，不是帮你打字，而是成为你数字工作的“神经末梢”。我把它扩展为三层能力：
- L1：输入增强（已实现）：纠错、补全、风格适配；
- L2：工作流串联（正在落地）：在输入时检测到“@meeting”，自动拉起日历App创建会议；输入“#bug-123”，自动在Jira里搜索该issue并插入摘要；
- L3：知识代理（规划中）：当输入“如何优化这个SQL”，它不只生成优化建议，而是：① 从你本地数据库连接配置中读取表结构；② 用
EXPLAIN分析当前查询计划；③ 结合你过去3个月提交的PR，推荐最匹配的优化模式。
这个演进路径的关键是“上下文感知”的持续深化。目前L1只读编辑器文本，L2要接入系统API（Calendar、Reminders、Jira REST），L3则需构建本地知识图谱——把你的代码库、笔记、邮件归档，用LlamaIndex建立向量索引。所有这些，都建立在开源可审计的基础上。闭源方案永远是个黑盒，你不知道它什么时候会悄悄把你的Jira token上传到厂商服务器。
6.2 社区共建：为什么你的贡献比想象中重要
这个项目的价值，70%不在代码，而在数据。比如“中文技术术语补全”这个功能，官方模型在训练时没见过“pydantic BaseModel”“React.memo”这类组合词。只有靠用户提交真实场景的bad case，才能持续优化。我们建立了极简的反馈机制：
- 用户长按候选栏任意一项，弹出“报告问题”菜单；
- 点击后，自动打包：当前输入文本、上下文快照、模型输出、系统日志（脱敏后）；
- 上传到GitHub Issues，标签自动打上
bad-case、zh-tech等； - 维护者每周用
git grep扫描这些case，挑出高频模式，生成新的微调数据集。
上周，一位用户提交了“在Vue3模板里输入v-mo，期望补全v-model却得到v-motion”的case。我们立刻用他的样本微调了轻量Ranker模型，准确率从63%提升到89%。这就是开源的力量：不是一个人在战斗，而是整个社区在为你定制AI。
6.3 我的个人体会：技术信仰与务实主义的平衡
写这篇博文时，我刻意避开了所有宏大叙事。不谈“改变人机交互范式”，不说“开启AGI普惠时代”。因为在我每天真实的使用中，它带来的改变很具体：
- 写技术文档时，
Ctrl+Space后，它自动补全“>>> import numpy as np”并插入三重反引号代码块，省去手动敲>>>和格式； - 回客户邮件，“感谢您的耐心等待”后面，它根据上文提到的“API响应慢”，自动续写“我们已定位到数据库连接池瓶颈，预计明天上线热修复”；
- 甚至在写这篇博文时，当我输入“开源精神”，它没有堆砌“自由”“共享”“协作”等空泛词汇，而是弹出“
MIT License”“copyleft”“permissive license”三个精准术语——因为它刚从我电脑里200个开源项目的LICENSE文件中，学到了这些词的共现模式。
感恩开源，不是感恩某个具体项目，而是感恩这种“可审视、可修改、可传承”的技术文化。它让我确信：最好的工具，永远诞生于真实需求的土壤，由真实用户用真实问题浇灌。而我的角色，不过是把这块土壤翻得更深一点，让更多人看见下面的根系。
这个输入法不会取代你思考，但它会默默记住你每一次思考的痕迹，并在下一次，把思考的起点，往前推一厘米。
