在与 AI 协作编程中，经常遇到一些大模型无法正确执行的情况。最常见的有：

• 任务死循环
• 模型无法修复环境问题
• 模型执行长任务后半段忘记上下文

一些使用经验

以我自己为例，我经常使用 Cline + Github Copilot 的组合。我很喜欢 Cline 的功能是 Checkpoint restore，它可以在执行错误的位置重新编辑提示词执行。这让我可以在相同的任务中调用不同的模型，观察他们处理问题的能力。

用作规划（Plan）的模型通常用 Deepseek-R1，Gemini 2.0 Flash Thinking，Claude 3.7。这里除了 Claude 3.7 能够比较准确给出计划外，其他模型多少都容易走「歪路」， 比如 Deepseek-R1 喜欢做一些多余的事情，让它翻译中文，它会调用 MCP 的翻译服务而不是自己翻译。

从经济角度考虑，解决简单问题 Gemini 2.0 Flash Thinking 是比较快速、经济的模型。复杂问题直接上 Claude 3.7 可能更容易控制成本。

用作执行任务（Act）的模型里，Deepseek-V3 表现非常不稳定，经常死循环或丢失上下文。Claude 太贵，而 Gemini 2.0 Flash 是相对准确且划算的模型。置于国产的 Qwen 系列模型不完全支持 Function Calling，Cline 也没有适配，所以暂时无法测试。

AI 编程疑难杂症的应对方法

最近读到AI Blindspots这篇文章，作者系统性整理了 AI 编程中遇到的问题和他的思路。对我非常有启发。我用 Agent 把它翻译成了中文并人工做了润色，你可以在这里读到：AI 编程的盲点。

概括起来，解决 AI 问题的核心要领还是三点：更准确的提示词、更完整的上下文、缩小问题规模。

相信随着技术的发展，编程范式会发生翻天覆地的变化。如果重构变得如此容易，那么马丁福勒的《重构》是否应该出一套 AI 时代下的新范式。如果文档不再是被人读，而是喂给模型当作上下文，那么文档的形态应该是什么样？是否提供一个向量化的文档接口供大模型调用，将是未来编程框架的新常态？

我对未来充满期待。

这几天面试被问到类似的问题，顺便看了看 Python 的源码，参考网上的教程，总结一下 yield 关键字在 C 层面是如何实现的。

举个栗子

我们先看一个 python 生成器函数的例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from dis import dis

def func():
 i = 4
 yield i
 print i

dis(func)
a =func()
a.next()
a.next()

使用 python 的库 dis 可以直接查看 python 虚拟机运行的字节码。dis(func)的打印如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

 6 0 LOAD_CONST 1 (4)
 3 STORE_FAST 0 (i)

 7 6 LOAD_FAST 0 (i)
 9 YIELD_VALUE
 10 POP_TOP

 8 11 LOAD_FAST 0 (i)
 14 PRINT_ITEM
 15 PRINT_NEWLINE
 16 LOAD_CONST 0 (None)
 19 RETURN_VALUE

我们猜测其中第二列(代表字节码偏移量)为 9 的指令YIELD_VALUE就是 yield 关键字的执行代码，进入 Python2.7.12 源码目录，在解释器执行字节码的主函数PyEval_EvalFrameEx中找到了下面一段：

1
2
3
4
5
6
7
8

 TARGET_NOARG(YIELD_VALUE)
 {
 retval = POP();
 f->f_stacktop = stack_pointer;
 why = WHY_YIELD;
 // 跳转到fast_yield处。fast_yield里处理了一下状态位然后返回结果
 goto fast_yield;
 }

其中TARGET_NOARG为封装了case语句的宏，这句话的意思是，如果字节码是YIELD_VALUE，就把栈顶元素赋值给retval，然后跳转到fast_yield处，fast_yield处代码进行了一些状态判断后直接返回了retval。

生成器是如何记录代码返回位置的

显然，如果这时候调用代码a.next()就会直接返回 yield 后边的表达式结果。这对应了上面 C 代码的fast_yield部分，那生成器怎么记录上次执行的位置并在下一次调用a.next()的时候从上次的位置继续执行的呢？

Python 在解释代码时，是将代码块加载为一个叫 PyFrameObject 的对象，这个对象代表了当前运行的栈帧。PyFrameObject 里有个f_lasti变量用于保存代码当前执行到了字节码的哪个位置。在第二次执行a.next()时，生成器对象把之前携带了f_lasti的 PyFrameObject 当参数传给PyEval_EvalFrameEx，在PyEval_EvalFrameEx里的执行一个 JUMPTO 就直接跳转到了上一次结束生成器时的字节码位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

PyObject *
PyEval_EvalFrameEx(PyFrameObject *f, int throwflag)
{
...
#define FAST_DISPATCH() \
 { \
 if (!lltrace && !_Py_TracingPossible) { \
 f->f_lasti = INSTR_OFFSET(); \
 goto *opcode_targets[*next_instr++]; \
 } \
 // 跳转到fast_next_opcode处
 goto fast_next_opcode; \
 }
...
fast_next_opcode:
 f->f_lasti = INSTR_OFFSET();

 /* line-by-line tracing support */

 if (_Py_TracingPossible &&
 tstate->c_tracefunc != NULL && !tstate->tracing) {
 ...
 /* Reload possibly changed frame fields */
 // 按照f->f_lasti中的偏移量跳转字节码
 JUMPTO(f->f_lasti);
}

其中INSTR_OFFSET宏正是字节码的偏移量。

1
2
3
4
5

#define INSTR_OFFSET() ((int)(next_instr - first_instr))

// co->co_code里保存的是字节码
first_instr = (unsigned char*) PyString_AS_STRING(co->co_code);
next_instr = first_instr + f->f_lasti + 1;

所以生成器对象每次执行结束都把字节码的偏移量记录下来，并把运行状态保存在 PyFrameObject 里，下一次运行时生成器时，python 解释器直接按照偏移量寻找下一个字节码指令。

原文地址： http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html

本文假设你已经具有一定分布式计算的基础知识。你将在第一部分看到以下内容：

• ZooKeeper数据模型
• ZooKeeper Sessions
• ZooKeeper Watches
• 一致性保证(Consistency Guarantees)

接下来的4小节讲述了程序开发的实际应用：

• 创建模块——ZooKeeper操作指引
• 编程语言接口
• 简单示例演示程序的结构
• 常见问题和故障

本文的附录中包含和ZooKeeper相关的有用信息。

ZooKeeper的数据模型

ZooKeeper有一个类似分布式文件系统的命名体系。区别在于Zookeeper每个一个节点或子节点都可以拥有数据。节点路径是一个由斜线分开的绝对路径，注意没有相对路径。只要满足下面要求的unicode字符都可以作为节点路径：

• 空字符不能出现在路径名
• 不能出现以下字符: \u0001 - \u0019 and \u007F - \u009F
• 以下字符不允许使用: \ud800 -uF8FFF, \uFFF0-uFFFF, \uXFFFE - \uXFFFF (where X is a digit 1 - E), \uF0000 - \uFFFFF
• 字符".“可以作为一个名字的一部分, 但是”.“和”..“不能单独作为相对路径使用, 以下用法都是无效的: “/a/b/./c"或者”/a/b/../c”
• “zookeeper"为保留字符

ZNodes

ZooKeeper树结构中的节点被称为znode。各个znode维护着一组用来标记数据和访问权限发生变化的版本号。这些版本号组成的状态结构具有时间戳。Zookeeper使用版本号和时间戳来验证缓存状态，调整更新。 每次znode中的数据发生变化，znode的版本号增加。例如，每当一个客户端恢复数据时，它就接收这个版本的数据，而当一个客户端提交了更新或删除记录，它必须同时提供这个znode当前正在发生变化的数据的版本。如果这个版本和目前真实的版本不匹配，则提交无效。 __提示，在分布式程序中，一个字节点可以代表一个通用的主机，服务器，集群中的一员，客户端程序等。但是在Zookeeper中，znode代表数据节点，Servers代表组成了Zookeeper服务的机器; quorum peers refer to the servers that make up an ensemble; 客户端代表任何使用ZooKeeper服务的主机或程序。

znode作为对程序开发来说最重要的信息，有几个特性需要特别关注下：

Watches 客户端可以在znode上设置Watch。znode发生的变化会触发watch然后清除watch。当一个watch被触发，Zookeeper给客户端发送一个通知。更多关于watch的内容请查看ZooKeeper Watches一节。

数据存取 命名空间中每个znode中的数据读写是原子操作。读操作读取znode中的所有数据位，写操作则替换所有数据。每个节点都有一个访问权限控制表（ACL）来标记谁可以做什么。 zookeeper不是设计成普通的数据库或大型对象存储的。它是用来管理coordination data。coordination data包括配置文件、状态信息、rendezvous等。这些数据结构的一个共同特点就是相对较小——以千字节为准。Zookeeper的客户端和服务会检查确保每个znode上的数据小于1M，实际平均数据要远远小于1M。 大规模数据的操作会引发一些潜在的问题并且延长在网络和介质之间传输的时间。如果确实需要大型数据的存储，那么可以采用如NFS或HDFS之类的大型数据存储系统，亦或是在zookeeper中存储指向存储位置的指针。

临时节点（Ephemeral Nodes） zookeeper还有临时节点的概念，这些节点的生命周期依赖于创建它们的session是否活跃。session结束时节点即被销毁。也由于这种特性，临时节点不允许有子节点。

序列节点——命名不唯一 当你创建节点的时候，你会需要zookeeper提供一组单调递增的计数来作为路径结尾。这个计数对父znode是唯一的。用%010d的格式——用0来填充的10位数（计数如此命名是为了简单排序）。例如”0000000001"，注意计数器是有符号整型，超过表示范围会溢出。

ZooKeeper中的时间

zookeeper有很多记录时间的方式：

• Zxid(ZooKeeper Transaction Id)： zookeeper每次发生改动都会增加zxid，zxid越大，发生的时间越靠后。
• Version numbers： 对znode的改动会增加版本号。版本号包括version (znode上数据的修改数), cversion (znode的子节点的修改数), aversion (znode上ACL（权限）的修改数)。
• Ticks : 多个server构成zookeeper服务时，各个server用ticks来标记如状态上报、连接超时等事件。ticks time还间接反映了session超时的最小值（两次tick time）；如果客户端请求的最小session timeout低于这个最小值，服务端会通知客户端最小超时置为这个最小值。
• Real time : 除了每次znode创建或改动时候将时间戳记录到状态结构中外，zookeeper不使用时钟时间。

ZooKeeper状态结构(Stat Structure)

存在于znode中的状态结构，由以下各个部分组成：

• czxid - znode创建产生的zxid
• mzxid - znode最后一次修改的zxid
• ctime - znode创建的时间的绝对毫秒数
• mtime - znode最后一次修改的绝对毫秒数
• version - znode上数据的修改数
• cversion - 子节点修改数
• aversion - znode的ACL修改数
• ephemeralOwner - 临时节点的所有者的session id。如果此节点非临时节点，该值为0
• dataLength - znode的数据长度
• numChildren - znode子节点数

ZooKeeper Sessions

客户端通过创建一个handle和服务端建立session连接。一旦创建完成，handle就进入了CONNECTING状态，客户端库尝试连接一台构成zookeeper的server，届时进入CONNECTED状态。通常情况下操作会介于这两种状态之间。 一旦出现了不可恢复的错误：如session中止，鉴权失败或者应用直接结束handle，则handle会进入到CLOSED状态。下图是客户端的状态转换图：

状态转换图

应用在创建客户端session时必须提供一串逗号分隔的主机号:端口号，每对主机端口号对应一个ZooKeeper的server（如：“127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”），客户端库会尝试连接任意一台服务器，如果连接失败或是客户端主动断开连接，客户端会自动继续与下一台服务器连接，直到连接成功。

3.2.0版本新增内容: 一个新的操作“chroot”可以添加在连接字符串的尾部，用来指明客户端命令运行的根目录地址。类似unix的chroot命令，例如： “127.0.0.1:4545/app/a” or “127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a”，说明客户端会以"/app/a"为根目录，所有路径都相对于根目录来设置，如"/foo/bar"的操作会运行在"/app/a/foo/bar"。 这一特性在多用户环境下非常好用，每个使用zookeeper服务的用户可以设置不同的根目录。

当客户端获得和zookeeper服务连接的handle时，zookeeper会创建一个Zookeeper session分配给客户端，用一个64-bit数字表示。一旦客户端连接了其他服务器，客户端必须把这个session id也作为连接握手的一部分发送。出于安全目的，zookeeper给session id创建一个密码，任何zookeeper服务器都可以验证密码。 当客户端创建session时密码和session id一起发送到客户端来，当客户端重新连接其他服务器时，同时要发送密码和session id。

zookeeper客户端库里有一个创建zookeeper session的参数，叫做session timeout（超时），用毫秒表示。客户端发送请求超时，服务端在超时范围内响应客户端。session超时最小为2个ticktime，最大为20个ticktime。zookeeper客户端API可以协调超时时间。 当客户端和zookeeper服务器集群断开时，它会搜索session创建时的服务器列表。最后，当至少一个服务器和客户端重新建立连接，session或被重新置为"connected"状态（超时时间内重新连接），或被置为"expired（过期）“状态（超出超时时间）。不建议在断开连接后重新创建session。ZK客户端库会帮你重新连接。特别地，我们将启发式学习模式植入客户的库中来处理类似“羊群效应”等问题。只有当你的session过期时才重新创建（托管的）。 session过期的状态转换图示例同过期session的watcher：

1. ‘connected’ : session正确创建，客户端和服务集群正常连接
2. …. 客户端从服务器集群断开
3. ‘disconnected’ : 客户端失去和服务器集群的连接
4. …. 过了一段时间, 超过了集群判定session过期的超时时间, 客户端并没有发觉自己和服务集群断开了连接
5. …. 又过一段时间, 客户端恢复了同集群的网络连接
6. ’expired’ : 最终客户端重新连上集群，然后被通知已经到期

另一个session建立时zookeeper需要的参数是默认watcher（监视者）。在客户端发生任何变化时，watcher都会发出通知。例如客户端失去和服务器的连接、客户端session到期等。watcher默认的初始状态是disconnected。（也就是说任何状态改变事件都由客户端库发送到watcher）。当新建一个连接时，第一个发送给watcher的事件通常就是session连接事件。

客户端发送请求会使session保持活动状态。客户端会发送ping包（译者注：心跳包）以保持session不会超时。Ping包不仅让服务端知道客户端仍然活动，而且让客户端也知道和服务端的连接没有中断。Ping包发送时间正好可以判断是否连接中断或是重新启动一个新的服务器连接。

和服务器的连接建立成功，当一个同步或异步操作执行后，有两种情况会让客户端库判断失去连接：

1. 应用在已经失效的session上请求了一个操作时
2. zookeeper服务器有一个等待中的操作时，客户端会从那台服务器断开连接。即服务器有等待的异步调用。

3.2.0版本新增内容 —— SessionMovedException 一个客户端无法查看的内部异常SessionMovedException。这个异常发生在服务端收到一个请求，这个请求的session已经在另一个服务器上重新连接。发生这种情况的原因通常是客户端发送完请求后，由于网络延时，客户端超时重新和其他服务器建立连接，当请求包到达第一台服务器时，服务器发现session已经移除并关闭了和客户端的连接。客户端一般不用理会这个问题，但是有一种情况值得注意，当两台客户端使用事先存储的session id和密码试图创建同一个连接时，第一台客户端重建连接，第二台则会被中断。

ZooKeeper Watches

所有zookeeper的读操作——getData(), getChildren(), exists()——都可以设置一个watch。Zookeeper的watch的定义是：watch事件是一次性触发的，发送到客户端的。在监视的数据发生变化时产生watch事件。以下三点是watch(事件)定义的关键点：

• 一次性触发: 当数据发生变化时，一个watch事件被发送给客户端。例如，如果一个客户端做了一次getData("/znode1", true)然后节点/znode1发生数据变化或删除，这个客户端将收到/znode1的watch事件。如果/znode1继续发生改变，不会再有watch发送，除非客户端又做了其他读操作产生了新的watch。
• 发送给客户端: 这就意味着，事件在发往客户端的过程中，可能无法在修改操作成功的返回值到达客户端之前到达客户端。watch是异步发送给watchers的。zookeeper提供一种保证顺序的方法：客户端在第一次看到某个watch事件之前不可能看到产生watch的修改的返回值。网络延时或其他因素可能导致不同客户端看到watch并返回不同时间更新的返回值。关键的一点是，不同的客户端看到发生的一切都必须是按照相同顺序的。
• watch依附的数据: 这是说改变一个节点有不通方式。用好理解的话说，zookeeper维护两组watch：data watch和child watch。getData()和exists()产生data watch。getChildren()引起child watch。watch根据数据返回的种类不同而不同。getData()和exists()返回关于节点的数据信息，而getChildren()返回子节点列表。因此setData()触发某个znode的data watch（假设事件成功）。create()成功会触发被创建的znode上的data watch和在它父节点上的child watch。delete()成功会触发data watch和child watch（因为没有了子节点）。

watch在客户端已连接上的服务器里维护，这样可以保证watch轻量便于设置，维护和分发。当客户端连接了一台新的服务器，watch会在任何session事件时触发。当断开和服务器的连接时，watch不会触发。当客户端重新连接上时，任何之前注册过的watch都会重新注册并在需要的时候被触发。一般来说这一切都是透明的。只有一种可能会丢失watch：当一个znode在断开和服务器连接时被创建或删除，那么判断这个znode存在的watch因未创建而找不到。

ZooKeeper如何保证watch可靠性

zookeeper有如下方式：

• watch与其他事件、watch、异步回复保持有序，Zookeeper客户端库确保任何分发都是有序的。
• 客户端会在某个监视的znode数据更新之前看到这个znode的watch事件。
• watch事件的顺序由Zookeeper服务端观察到的更新顺序决定。

watch注意事项

• watch是一次性触发的；如果你收到watch事件后还想继续得到后续更改的通知，你需要再生成（设置）一个watch。
• 由于watch是一次性触发，你在获取某事件和发送新的请求来得到watch这个操作之间，无法确保观察到Zookeeper中那个节点在这期间的所有修改。你要准备好应付这种情况出现：znode会在收到事件和再次设置新事件（译者注：对节点的操作）之间发生了多次修改。（你可能并不关心，但是必须了解这可能发生）
• watch对象，或是function/context对，只会在得到通知时触发一次。例如，如果一个watch对象同时用来监控某个目标文件是否存在和监听getData()，之后那个文件被删除了。那么这个watch对象只会触发一次文件删除事件通知。
• 如果你断开了同服务器的连接（例如服务器挂了），你在重新连上之前得不到任何watch。出于这种原因，session event会被发送给所有重要的watch handler。可以使用session事件进入安全模式：当断开连接时你收不到任何事件，这样你的进程可以在那种模式下稳健地执行。(译者注：可以通过发送session event使客户端进入安全模式（伪断开连接状态），在安全模式你可以修改代码而不用担心程序收到事件通知)

使用ACL控制ZooKeeper访问权限

zookeeper使用ACL来控制对znode（zookeeper的数据节点）的访问权限。ACL的实现方式和unix的文件权限类似：用不同位来代表不同的操作限制和组限制。与标准unix权限不同的是，zookeeper的节点没有三种域——用户，组，其他。zookeeper里没有节点的所有者的概念。取而代之的是，一个由ACL指定的id集合和其相关联的权限。 注意，一个ACL只从属于一个特定的znode。对这个znode子节点也是无效的。例如，如果/app只有被ip172.16.16.1的读权限，/app/status有被所有人读的权限，那么/app/status可以被所有人读，ACL权限不具有递归性。 zookeeper支持插件式认证方式，id使用scheme:id的形式。scheme是id对应的类型方式，例如ip:172.16.16.1就是一个地址为172.16.16.1的主机id。 当客户端连接zookeeper并且认证自己，zookeeper就在这个与客户端的连接中关联所有与客户端一致的id。当客户端访问某个znode时，znode的ACL会重新检查这些id。ACL的表达式为(scheme:expression,perms)。expression就是特殊的scheme，例如，(ip:19.22.0.0/16, READ)就是把任何以19.22开头的ip地址的客户端赋予读权限。

ACL权限

ZooKeeper支持下列权限：

• CREATE：允许创建子节点
• READ：允许获得节点数据并列出所有子节点
• WRITE：允许设置节点上的数据
• DELETE：允许删除子节点
• ADMIN：允许设置权限

CREATE和DELETE操作是更细的粒度上的WRITE操作。有一种特殊的情况：

• 你想要A获得操作zookeeper上某个znode的权限，但是不可以对其子节点进行CREATE和DELETE。
• 只CREATE不DELETE：某个客户端在上一级目录上通过发送创建请求创建了一个zookeeper节点。你希望所有客户端都可以在这个节点上添加，但是只有创建者可以删除。（这就类似于文件的APPEND权限）

zookeeper没有文件所有者的概念，但有ADMIN权限。在某种意义上说，ADMIN权限指定了所谓的所有者。zookeeper虽然不支持查找权限（在目录上的执行权限虽然不能列出目录内容，却可以查找），但每个客户端都隐含着拥有查找权限。这样你可以查看节点状态，但仅此而已。（这有个问题，如果你在不存在的节点上调用了zoo_exists()，你将无权查看）

内建ACL模式

ZooKeeper有下列内建模式：

• world 有独立id，anyone，代表任何用户。
• auth 不使用任何id，代表任何已经认证过的用户
• digest 之前使用了格式为username:pathasowrd的字符串来生成一个MD5哈希表作为ACL ID标识。在空文档中发送username:password来完成认证。现在的ACL表达式格式为username:base64, 用SHA1编码密码。
• ip 用客户端的ip作为ACL ID标识。ACL表达式的格式为addr/bits，addr中最有效的位匹配上主机ip最有效的位。

ZooKeeper C client API

插件式ZooKeeper认证

zookeeper运行于复杂的环境下，有各种不同的认证方式。因此zookeeper拥有一套插件式的认证框架。内建认证scheme也是使用这套框架。 为了便于理解认证框架的工作方式，你首先要了解两种主要的认证操作。框架首先必须认证客户端。这步操作通常在客户端连接服务器的同时完成并且将从客户端发过来的（或从客户端收集来的）认证信息关联此次连接。认证框架的第二步操作是在ACL中寻找关联的客户端的条目。ACL条目是<idspec, permissions>格式。idspec可能是一个关联了连接的，和认证信息匹配的简单字符串，也可能是评估认证信息的表达式。这取决于认证插件如何实现匹配。下面是一个认证插件必须实现的接口：

public interface AuthenticationProvider {
String getScheme();
KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]);
boolean isValid(String id);
boolean matches(String id, String aclExpr);
boolean isAuthenticated();
}

第一个方法getScheme返回一个标识该插件的字符串。由于我们支持多种认证方式，认证证书或者idspec必须一直加上scheme:作为前缀。zookeeper服务器使用认证插件返回的scheme判断哪个id适用于该scheme。 当客户端发送与连接关联的认证信息时，handleAuthentication被调用。客户端指定和认证信息相应的模式。zookeeper把信息传给认证插件，认证插件的getScheme匹配scheme。实现handleAuthentication的方法通常在判断信息错误后返回一个error，或者在确认连接后使用cnxn.getAuthInfo().add(new Id(getScheme(), data))

认证插件在设置和ACL中都有涉及。当对某个节点设置ACL时，zookeeper服务器会传那个条目的id给isValid(String id)方法。插件需要判断id的连接来源。例如，ip:172.16.0.0/16是有效id，ip:host.com是无效id。如果新的ACL包括一个"auth"条目，就用isAuthenticated判断该scheme的认证信息是否关联了连接，是否可以被添加到ACL中。一些scheme不会被包含到auth中。例如，如果auth已经指定，客户端的ip地址就不作为id添加到ACL中。 在检查ACL时zookeeper有一个matches(String id, String aclExpr)方法。ACL的条目需要和认证信息相匹配。为了找到和客户端对应的条目，zookeeper服务器寻找每个条目的scheme，如果对某个scheme有那个客户端的认证信息，matches(String id, String aclExpr)会被调用并传入两个值，分别是事先由handleAuthentication 加入连接信息中认证信息的id，和设置到ACL条目id的aclExpr。认证插件用自己的逻辑匹配scheme来判断id是否在aclExpr中。

有两个内置认证插件：ip和digest。附加插件可以使用系统属性添加。在zookeeper启动过程中，会扫描所有以"zookeeper.authProvider"开头的系统属性。并且把那些属性值解释为认证插件的类名。这些属性可以使用-Dzookeeeper.authProvider.X=com.f.MyAuth或在服务器设置文件中添加条目来创建：

authProvider.1=com.f.MyAuth
authProvider.2=com.f.MyAuth2

注意属性的后缀是唯一的。如果出现重复的情况-Dzookeeeper.authProvider.X=com.f.MyAuth -Dzookeeper.authProvider.X=com.f.MyAuth2，只有一个会被使用。同样，所有服务器都必须统一插件定义，否则客户端用插件提供的认证schemes连接服务器时会出错。

一致性保证

ZooKeeper是一个高性能，可扩展的服务。读和写操作都非常快速。之所以如此，全因为zookeeper有数据一致性的保证：

顺序一致性 客户端的更新会按照它们发送的次序排序。

原子性 更新的失败或成功，都不会出现半个结果。

单独系统镜像 不管客户端连哪个服务器，它看来都是同一个。

可靠性 一旦更新生效，它就会一直保存到下一次客户端更新。这就有两个推论：

1. 如果客户端得到成功的返回值，说明更新生效了。在一些错误情况下（连接错误，超时等）客户端不会知道更新是否生效。虽然我们使失败的几率最小化，但是也只能保证成功的返回值情况。（这就叫Paxos算法的单调性条件）
2. 客户端能看到的更新，即使是渡请求或成功更新，在服务器失败时也不会回滚。

时效性 客户端看到的系统状态在某个时间范围内是最新的（几十秒内），任何系统更改都会在该时间范围内被客户端发现。否则客户端会检测到断开服务。

用这些一致性保证可以在客户端中构造出更高级的程序如 leader election, barriers, queues, read/write revocable locks(无须在zookeeper中附加任何东西)。更多信息Recipes and Solutions

zookeeper不存在的一致性保证： 多客户端同一时刻看到的内容相同 zookeeper不可能保证两台客户端在同一时间看到的内容总是一样，由于网络延迟等原因。假设这样一个场景，A和B是两个客户端，A设置节点/a下的值从0变为1，然后让B读/a，B可能读到旧的数据0。如果想让A和B读到同样的内容，B必须在读之前调用zookeeper接口中的sync()方法。

编程接口

常见问题和故障

下面是一些常见的陷阱：

1. 如果你使用watch，你必须监控好已经连接的watch事件。当ZooKeeper客户端断开和服务器的连接，直到重新连接上这段时间你都收不到任何通知。如果你正在监视znode是否存在，那么你在断开连接期间收不到它创建和销毁的通知。
2. 你必须测试ZooKeeper故障的情况。在大多数服务器都可用的情况下，ZooKeeper是可以维持工作的。关键问题是你的客户端程序是否能察觉到。在实际情况下，客户端与ZooKeeper的连接有可能中断（多数时候是因为Zookeeper故障或网络中断）。Zookeeper的客户端库关注于如何让你重新连接并且知道发生了什么。但是同时你也必须确保能够恢复你的状态和发送失败的请求。努力在测试库里测出这些问题，而不是在产品里——用几台服务器组成的zookeeper集群测试这个问题，尝试让它们重启。
3. 客户端维护的服务器列表必须和现有的服务器列表一致。如果客户端的列表是现有服务器列表的子集，还可以在非最佳状态工作，但是如果客户端列表里的服务器不在现有集群里你就悲剧了。
4. 注意存放事务日志的位置。性能评测最重要的部分就是日志，ZooKeeper会在回复响应之前先把日志同步到磁盘上。为了达到最佳性能，首选专用的磁盘来存日志。把日志放在繁忙的磁盘上会降低效率。如果你只有一个磁盘，就把记录文件放在NFS上然后增加SnapshotCount。这样虽然无法完全解决问题，但能缓解一些。
5. 正确地设置你java的堆空间大小。这是避免频繁交换的有效措施。无用的访问磁盘会让你的效率大打折扣。记住，在ZooKeeper中，一切都是有序的，如果一个服务器访问了磁盘，所有的服务器都会同步这个操作。

其他资料链接请自行官网查看。

注意，ubuntu 和 xubuntu 安装上有一定差别，请严格按照你选择的系统版本流程安装

ubuntu

准备工作

分区

这一步可以用命令行实现，也可以在 mac 下直接用磁盘工具分区，初学者建议后者。有经验的朋友可以在网上查询 diskutils 的用法，这是 mac 提供的分区工具

使用磁盘工具，打开左侧最上边磁盘位置（不是 macosx，而是整个硬盘）的选项，右边会出现分区标签。选择分区，你可以用鼠标拖动轻松将 macos 的一部分划分给 ubuntu 使用。分区格式可以选择 mac 日志文件。其实选什么都一样，等会还要重新格式化。

把 iso 镜像转化为苹果电脑识别的 img 镜像

hdiutil convert /path/to/ubuntu.iso -format UDRW -o /path/to/target.img

命令中path/to/ubuntu.iso是你下载的 iso 路径，path/to/target.img自然是你要保存成 img 的路径

插入 U 盘，刻录镜像

先运行如下命令查询你 U 盘的设备名

diskutil list

这里假设 U 盘是 disk1，执行

diskutil unmountDisk /dev/disk1

接下来执行命令刻录，

sudo dd if=/path/to/downloaded.img of=/dev/disk1 bs=1m

ubuntu 官网针对上一条命令可能出现的两种错误提示给出了解决办法：

1. If you see the error dd: Invalid number ‘1m’, you are using GNU dd. Use the same command but replace bs=1m with bs=1M.

2. If you see the error dd: /dev/disk1: Resource busy, make sure the disk is not in use. Start the ‘Disk Utility.app’ and unmount (don’t eject) the drive.

好了，刻完就可以重启安装了。重启后按住option会看到一个 refit 命名的移动设备图标，点进去就开始安装了。

安装过程

安装过程可以参考网上其他人的帖子。一般有两种方式

1. 选择ubuntu和mac os x共存，系统会自动被安装到空闲分区。
2. 选择其他选项，可以自己手动分区，我一般是选这个来手动分区。

假设你选了其他选项就会进入分区的窗口，这时你就会看到所有磁盘分区的情况，刚才在 mac 下给 ubuntu 预先分好一块空闲分区也在其中，名字可能叫 disk02，或者 disk03 什么的。 接下来要进行四次分区。这一段分区方法参考了百度经验上一个网友的教程，我进行了 2 处修改，原帖地址http://jingyan.baidu.com/article/60ccbceb18624464cab197ea.html

第一次分区：

点你刚才留出来的“空闲”分区，点“+”，进行如下设置：
挂载点：“/”
大小：22000MB
新分区的类型：主分区
新分区的位置：空间起始位置
用于：EXT4日志文件系统

第二次分区：

“空闲”处，继续点“+”，如下设置，
挂载点：（不设置）
大小：4096MB
新分区的类型：逻辑分区
新分区的位置：空间起始位置
用于：交换空间

第三次分区：

“空闲”处，继续点“+”，如下设置，
挂载点：/boot
大小：200MB
新分区的类型：逻辑分区
新分区的位置：空间起始位置
用于：EXT4日志文件系统

第四次分区：

“空闲”处，继续点“+”，如下设置，
挂载点：/home
大小：（剩余全部空间，剩下显示多少，就多少）
新分区的类型：逻辑分区
新分区的位置：空间起始位置
用于：EXT4日志文件系统

分区设置完毕后，下方还有一项“安装启动引导器的设备”，macbookpro 用户需要选择/boot 这个分区所在磁盘位置。

开机引导程序 rEFIT

安装完 ubuntu，重启在 mac 下下载安装 rEFIt。安装好后在终端里输入/efi/refit/. enable-always.sh启动 rEFIt。重启，你就会看到 ubuntu 的选项。

Xubuntu(估计 Lubuntu 和 Kubuntu 也应该适用，仅是猜想。)

准备工作

如何刻录镜像到移动设备

这个问题很重要，如果你下载了 iso 格式的 Xubuntu 系统镜像， 你需要将该镜像不经过任何转换的完整刻录到移动设备或光盘上 （我使用的是 unetbootin 这个软件，开源，跨平台，操作简便）。 注意，绝对不可以将 iso 格式转换成 img（mac 镜像）后刻录。 这样会导致 ubuntu 部分版本无法安装 grub 引导器。

开机引导程序 rEFIt

安装完的系统无法被 mac 直接引导，所以需要安装 rEFIt 引导。如果不想要安装它， 可以参考下边附录 1 里的安装方法。重新修改引导文件。

安装过程

1. 在官网下载 xubuntu 镜像，使用 uneetbootin 刻录到设备 上(mac 版的 unetbootin 貌似刻录 iso 有问题，可以在 windows 上下载该软件使用)。
2. 重启，开机界面按住option键，有个 windows 命名的移动设备图标，选中进入。
3. 安装过程不敷述, 装后重启
4. 从 mac 进入，安装 rEFIt，在 shell 里运行/efi/refit/. enable-always.sh启动 rEFIt
5. 重启，出现两个图标，苹果代表 mac，企鹅代表 linux。至此，完成安装过程。

ubuntu 或 Xubuntu 安装后的一些配置

打开系统配置文件，

sudo gedit /etc/rc.local

在 exit 0 前边加入下边对应的语句, 默认关闭功能键 Fn:

echo 2 > /sys/module/hid_apple/parameters/fnmode

设置默认亮度(数字 2565 可以修改任意亮度)（xubuntu 下不起作用，原因未知）

echo 2565 > /sys/class/backlight/intel_backlight/brightness

设置键盘灯亮度（数字 1 代表亮度):

echo 1 > /sys/class/leds/smc::kbd_backlight/brightness

附录 1

https://help.ubuntu.com/community/MacBookPro11-1/Saucy

这篇文章比较基础，是我在给 Java 程序员做 go 语言培训时用到的。

为什么要做依赖倒置（DIP）？

依赖倒置，或叫依赖反转、DIP，是软件开发非常重要的设计原则。很多程序员没有了解过相关知识，或者只从 Java Spring 知道大致思想。我今天想用一篇简短的文章，用 Go 语言做一个简单的例子，讲解一下怎么最简单地实现依赖倒置。

如果你还不知道它是什么，可以参考 wiki 中的描述，或者阅读马丁福勒关于 DIP 的文章。

依赖倒置原则要解决一个软件开发中常见的风险：依赖。

尝试回忆一下：

1. 当你尝试通过 Mock 方式屏蔽底层细节做测试时，你发现你要测试的类引用了大量框架提供的接口，导致你需要 mock 大量底层的实现。
2. 当你尝试修改一个旧的底层类，但是依赖该类的上层服务类太多，你一边担心造成副作用，一边在所有依赖的位置重构上层代码。

我们分析一下这两个场景：

场景 1 里，应用类依赖于框架提供的实现，导致应用类很难从框架上剥离出来，业内处理这种问题的方法叫控制反转（IoC, Inversion of Control）。即应用类不应该依赖框架，而是框架提供插槽一样，把应用类注册给框架，由框架统一调度应用，执行对应的方法。

场景 2 里，服务类依赖底层类，导致底层修改难度越来越大。解决办法是依赖注入（DI, Dependency Injection）。即上层类不直接引用底层类，而是在使用的地方把上层类依赖的底层类注入进来。

把这两个场景结合起来，就是依赖倒置原则的核心：

• 高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
• 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。

这两个原则保证了代码中模块的高内聚、低耦合，同时给 Mock、迭代更新模块创造了条件。

用 Go 语言实现它

假设现在要从一个用户的服务中查询用户的信息。有两个接口，UserRepository 作为数据层负责查询数据库， UserService 负责业务逻辑，它依赖 UserRepository。同时为了方便测试，我们还要写一个 Mock 的数据层实现。 整个结构如下图。

接下来非常轻松地，我们实现两个接口，并写了他们的实现类。同时我们还在 UserService 的实现类里写了一个 NewUserService，来把它依赖的 UserRepository 实现注入进来。

// 在 user_repository.go 中实现具体的接口
type UserRepository interface {
 GetByID(id int) (*User, error)
 Save(user *User) error
}

// ... 具体实现 UserRepository，略

// user_service.go 中实现
type UserService interface {
 GetUser(id int) (*User, error)
 CreateUser(name string, age int) error
}

// ... 具体实现 UserService，略

func NewUserService(repo UserRepository) UserService {
 return &UserServiceImpl{
 repo: repo,
 }
}

那么问题来了，可不可以直接在 user_service.go 中直接把 repository 引用进来呢？显然不行，因为这样，两个模块就形成了依赖关系。

这一点是依赖反转的核心，上层模块不直接引用下层模块，而是由执行的类来初始化 Service 并将依赖的下层服务注入进来。

// 在main.go 中
func main() {
 repo := &MySQLUserRepository{}
 userService := NewUserService(repo)
}

这样，当编写测试 Mock 代码时，不需要修改任何代码逻辑，直接在测试中将NewUserService 的参数替换成测试的假实例即可。

// 在 user_service_test.go 中
func TestUserService() {
 repo := &MockTestUserRepository{}
 userService := NewUserService(repo)
}

另外，如果数据层修改了实现，或者迁移到另外的数据库，你只需要修改两个地方：数据层的实现者和依赖注入者。对于调用者 UserService 则完全不受到影响。整个项目也不会形成依赖陷阱。

总结

依赖倒置原则的两个核心原则：

• 模块不依赖于其他模块，而是都依赖于抽象接口
• 抽象接口不依赖于实现，而实现依赖于抽象接口

在 Go 语言中实现这两条原则并不麻烦，只要将原本的调用方-实现方，转换成注册方-调用方-实现方。在 Go 中也有一些库和框架实现依赖反转，其实核心思想并没有差异。

Python 执行环境

在编译过程中，这些包含在 Python 源代码中的静态信息都会被 Python 编译器收集起来，编译的结果中包含了字符串，常量值，字节码等在源代码中出现的一切有用的静态信息。在 Python 运行期间，这些源文件中提供的静态信息最终会被存储在一个运行时的对象中，当 Python 运行结束后，这个运行时对象中所包含的信息甚至还会被存储在一种文件中。这个对象和文件就是我们这章探索的重点：PyCodeObject 对象和 pyc 文件。

在程序运行期间，编译结果存在于内存的 PyCodeObject 对象中；而 Python 结束运行后，编译结果又被保存到了 pyc 文件中。当下一次运行相同的程序时，Python 会根据 pyc 文件中记录的编译结果直接建立内存中的 PyCodeObject 对象，而不用再次对源文件进行编译了。

从文章摘录可见，python 生成的不是编译后的文件，而是.py文件对应的静态信息——PyCodeObject，这里包括了字节码指令序列、字符串、常量。每个名字空间(类、模块、函数)都对应一个独立的 PyCodeObject。(python 连编译后的文件里存的都是个对象！)

不被 import 的 py 文件不会生成 pyc。标准库里有 py_compile 等方法也可以生成 pyc。

import 机制 导入某个模块时，先查找对应的 pyc，如果没有 pyc 就生成然后 import 这个 pyc。(所以实际导入的并不是 py 文件，而是 py 文件编译后的 PyCodeObject)。

PyFrameObject Python 程序运行时的「执行环境」。参考操作系统执行可执行文件的过程。Python 也是将函数对应的执行环境封装成栈帧的形式加载进内存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

typedef struct _frame {
 PyObject_VAR_HEAD
 struct _frame *f_back; //执行环境链上的前一个frame
 PyCodeObject *f_code; //PyCodeObject对象
 PyObject *f_builtins; //builtin名字空间
 PyObject *f_globals; //global名字空间
 PyObject *f_locals; //local名字空间
 PyObject **f_valuestack; //运行时栈的栈底位置
 PyObject **f_stacktop; //运行时栈的栈顶位置
 ……
 int f_lasti; //上一条字节码指令在f_code中的偏移位置
 int f_lineno; //当前字节码对应的源代码行
 ……
 //动态内存，维护（局部变量+cell对象集合+free对象集合+运行时栈）所需要的空间
 PyObject *f_localsplus[1];
} PyFrameObject;

Python 标准库的sys._getframe()可以动态的在程序执行时获取当前内存中活跃的 PyFrameObject 信息。

LEGB 规则

即 python 作用域的查找顺序是local-enclosing-global-buildin。看下面代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

a = 1

def g():
 print a

def f():
 print a //[1]
 a = 2 //[2]
 print a

g()

代码在[1]处会抛出异常，原因是 python 在编译阶段就把静态数据(局部变量、全局变量、字节码)放入 pyc 里，执行到f()里时，查找到a是在 local 作用域里定义的而不是 global 里，但是此时 local 的 a 还没赋值，所以就会抛出异常。由此可见，python 作用域信息是在静态编译时就处理好了的。

Python 虚拟机运行框架

运行时环境是一个全局的概念，而执行环境实际就是一个栈帧，是一个与某个 Code Block 对应的概念。

在 PyCodeObject 对象的 co_code 域中保存着字节码指令和字节码指令的参数，Python 虚拟机执行字节码指令序列的过程就是从头到尾遍历整个 co_code、依次执行字节码指令的过程。

由上文引用可见，python 在编译阶段将代码块的字节码保存在 PyCodeObject 的 co_code 属性里，然后在执行阶段从头到尾遍历这个 co_code 属性解读字节码。

Python 运行时环境 Python 在运行时用 PyInterpreterState 结构维护进程运行环境，PyThreadState 维护线程运行环境，PyFrameObject 维护栈帧运行环境，三者是依次包含关系，如下图所示：

Python 虚拟机就是一个「软 CPU」，动态加载上述三种结构进内存，并模拟操作系统执行过程。程序执行后，先创建各个运行时环境，再将栈帧中的字节码载入，循环遍历解释执行。

Python 字节码

1
2
3

i = 1
0 LOAD_CONST 0 (1)
3 STORE_NAME 0 (i)

例如 python 的一条语句i=1可以解释为下面两行字节码，最左边的第 1 列数字代表这行字节码在内存中的偏移位置，第 2 列是字节码的名字(CPU 并不关心名字，它只是根据偏移量读出字节码，所以这个名字是方便阅读用的)，第 3 列是字节码的参数，如LOAD_CONST对应的数据在变量f->f_code->co_consts里，0 就是这个参数位于f->f_code->co_consts的偏移量。最后一列的括号里是从参数里取到的 value。

Python 的异常抛出机制

异常处理的操作都在Python/traceback.c文件里，python 每次调用一层函数，就创建改函数对应的 PyFrameObject 对象来保存函数运行时信息，PythonFrameObject 里调用 PyEval_EvalFrameEx 循环解释字节码，如果抛出异常就创建 PyTraceBackObject 对象，将对象交给上一层 PyFrameObject 里的 PyTracebackObject 组成链表，最后返回最上层 PyRun_SimpleFileExFlags 函数，该函数调用 PyErr_Print 遍历 PyTraceBackObject 链表打印出异常信息。

函数对象的实现

PyFunctionObject 是函数对象。在 python 调用函数时，生成 PyFunctionObject 对象，该对象的 f_global 指针用来将外层的全局变量传递给函数内部，然后在ceval.c文件的fast_function里解出 PyFunctionObject 对象里携带的信息，创建新的 PyFrameObject 对象(上文说过这个对象是维护运行时环境的)，最后调用执行字节码的函数PyEval_EvalFrameEx执行真正函数字节码。

Python 执行一段代码需要什么？ 从书中描述可见，python 执行一段代码需要做几件事：

• 从源码编译出 PyCodeObject 保存变量和字节码
• 执行阶段，从 PyCodeObject 里取出信息交给 PyFrameObject，执行 PyEval_EvalFrameEx 解释字节码
• 如果遇到函数调用，就把函数对应的代码段从 PyCodeObject 存入 PyFunctionObject 对象，然后把这个函数对象通过参数传给新创建的 PyFrameObject ，在内层空间执行 PyEval_EvalFrameEx 解释字节码
• 将结果或异常存入 PyFrameObject 的变量( 异常是存入 f_blockstack 里，外层判断 f_blockstack 里的数据是被 except 捕获还是没有捕获而继续下一步操作) 抛给外层

值得注意的是，python 在执行阶段，将对函数参数的键值查找，转换为索引查找，即在转换 PyCodeObject 为 PyFrameObject 时，将参数信息按位置参数、键参数按照一定顺序存储在 f_localsplus 变量中，再用索引来查找对应参数，而需要查找键值。这样提高了运行时效率。下图是foo('Rboert', age=5)在内存中的存储形式。

闭包的实现

Python 在编译阶段就把函数闭包内层和闭包外层使用的变量存入 PyCodeObject 中：

• co_cellvars：通常是一个 tuple，保存嵌套的作用域中使用的变量名集合；
• co_freevars：通常也是一个 tuple，保存使用了的外层作用域中的变量名集合。

在执行阶段，PyFrameObject 的 f_localsplus 中也为闭包的变量划分的内存区域，如下图所示：

元类

元类<type type>和其他类的关系如下图：

可调用性（callable） ，只要一个对象对应的 class 对象中实现了“call”操作（更确切地说，在 Python 内部的 PyTypeObject 中，tp_call 不为空）那么这个对象就是一个可调用的对象，换句话说，在 Python 中，所谓“调用”，就是执行对象的 type 所对应的 class 对象的 tp_call 操作。

Descriptor

在 PyType_Ready 中，Python 虚拟机会填充 tp_dict，其中与操作名对应的是一个个 descriptor 对于一个 Python 中的对象 obj，如果 obj.class对应的 class 对象中存在get、set和delete三种操作，那么 obj 就可称为 Python 一个 descriptor。

如果细分，那么 descriptor 还可分为如下两种：

1. data descriptor : type 中定义了get和set的 descriptor；
2. non data descriptor : type 中只定义了get的 descriptor。 在 Python 虚拟机访问 instance 对象的属性时，descriptor 的一个作用是影响 Python 虚拟机对属性的选择。从 PyObject_GenericGetAttr 的伪代码可以看出，Python 虚拟机会在 instance 对象自身的dict中寻找属性，也会在 instance 对象对应的 class 对象的 mro 列表中寻找

1. Python 虚拟机按照 instance 属性、class 属性的顺序选择属性，即 instance 属性优先于 class 属性；
2. 如果在 class 属性中发现同名的 data descriptor，那么该 descriptor 会优先于 instance 属性被 Python 虚拟机选择

引申：Python 黑魔法 Descriptor (描述器)

• http://www.jianshu.com/p/250f0d305c35
• http://pyzh.readthedocs.io/en/latest/Descriptor-HOW-TO-Guide.html

Bound Method 和 Unbound Method

假设有下面两种对类方法的调用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

class A(object):
 def f(self):
 pass

a = A()
# [1]
a.f()

# [2]
A.f(a)

# [3]
func = a.f
func()

在代码[1]里，实例 a 调用类方法 f，python 底层会自动完成实例 a 和类方法 f 之间的绑定动作(调用func_ descr_get(A.f, a, A)，将实例地址和函数对象 PyFunctionObject 封装到一个 PyMethodObject)，而代码[2]里直接通过 A 调用，则 f 为非绑定的 PyMethodObject，里面没有实例信息，需要传入 a。

比较绑定方法与非绑定方法可知，通过[1]的方式每次都要绑定一次实例，开销非常大，下图比较的是[1]和[3]两种方式，绑定操作的执行次数。

结论： 调用类实例绑定的方法时，如果方法执行次数非常多，最好将方法赋值给一个变量，防止重复绑定增加开销

我想很多时候我们下决心做一件事，都要征求周围人的建议。这些建议有好有坏。坏的建议不但帮不了你，还会歪曲你对事实的认识。最近我在研究系统学习英文的方法，偶然在豆瓣小站里看到了开头那段话，对此深表认同。以我个人健身的经历，在报名私教课之前也寻求过很多人的建议。大部分会告诉你，健身(减肥)最重要的就是坚持。他们还会煞有介事的告诉你要「管住嘴，迈开腿」。在这一年里，我减掉了大概 25KG 体重，最大的感受——如果没有教练指导，我自己是断然不会坚持下来的。大部分的建议都像开头引用的那段话一样，是假大空的虚话，废话。

「任何一个通过自我磨练掌握了某一项具体技能或者在某领域内有一定造诣的人，都会对该领域有着起码的基本认知和独特的个人总结，如果你向其请教，得到的断然不会是“努力去做或者坚持最重要”之类的假大空的虚话」
—— 豆瓣英语学习大神 恶魔奶爸 Sam

怎样征求有用的建议？结合我这些年减肥失败的教训，笼统的概括为：如果你要做一件长期投入的事儿，那么请咨询跟你情况类似，且做成了这件事的人。

首先「情况类似」很重要。因为很多人是科班出身，比如健身教练，他们大部分从上学起就被动养成了科学饮食、运动的好习惯。这些习惯并不是主动思考之后产生的，所以这些人在传授你知识时往往模糊不清的告诉你应该如何做，却说不出所以然。再比如英语系的学生就很难告诉你行之有效的英语学习方法，他们会告诉你大量看美剧英剧，背单词。但是你根本没有他们的学习环境，几乎不可能坚持下来。在语言学习中有「可理解输入」的概念，简单解释就是——你必须接受那些「你能够理解」的知识，否则你就吸收不了(记不住)。同理，知识在灌输给我们时候，如果不解释清楚来由，我们就很难有深刻认识。所以征求建议的对象如果跟你情况类似，你往往能听到更加切实可行的建议，比如在某个阶段应该注意什么，可能片面，但是有效。比如我在健身初期，咨询同学大伟很多健身的入门知识，关于人体代谢率，关于自重训练。这些东西，科班出身的教练通常不会细致地讲解给我。

其次「要征求做成了这件事的人」，这就是开头那段话的意义，那些没做成这件事儿的人，大都输在了「坚持」这两个字上。在把这一信息转告别人时，这些人就会主观放大坚持的重要性。你去征求这些自己都没成事儿的人建议，得到的都是些「管住嘴，迈开腿」，「坚持不懈」之类的屁话。我这一年锻炼和饮食的心得就是不断学习，反复修订计划和总结经验。另外还有一种傻逼理论「每个人都有各自的特点，要针对性制定计划，没有一种通用的解决办法」。倘若真是这样，还上学干什么？搞科研做什么？管理学、经济学都要歇菜了。别用个体差异给自己找借口了。

我猜很多有主见，独立思考的人都会认同一句话。这句话是罗永浩在一次鲁豫有约采访时候说的——「我们周围大部分人都是笨蛋」。虽然老罗最近在做手机上栽了大跟头，但是大多数人一辈子连栽这样跟头的机会都没有就入土了。可是骂他的成千上万人里有多少是经历过这过程的呢？传播那些人云亦云的虚话，不过是懒于思考，不求上进的人找好的借口。他们自己做不到的，就理所当然认为你也做不到。抱着「周围大部分人都是笨蛋」的理念，积极地去跟「对的人」征求「有价值」的建议，我相信一定能有所收获。