.. Kenneth Lee 版权所有 2026 :Authors: Kenneth Lee :Version: 0.1 :Date: 2026-04-01 :Status: Draft AI架构设计入门 ************** 介绍 ==== 最近有同事体验了AI编程，她不是专业做编程的，所以主要是站在一个“不会写程序”的AI 编程体验者的角度来谈这个问题的，她提到她在这个过程中消耗了很多时间，这让她意识 到她的工程思维不够，缺乏对前期模块划分，功能界定，导致程序越来越大以后，AI开始 遗忘她的原始需求了。她希望我给她科普一点架构设计的知识，以便更好控制AI的输出， 让它更有工程思维，不要犯蠢。 我觉得这个不但是这种Vibe Coding的问题，也是一个普遍的架构设计问题，所以我在这 里做了这个总结，不但希望给她提供帮助，更大程度上，希望从AI编程的角度，总结一下 架构设计的本质。 理解AI思维 ========== 抛开内部的算法细节，AI的算法基本上是这样的：算法本身有一个巨大的参数矩阵（比如 1亿参数，10亿参数，等等）这样。然后像人学习一样，不断用程序，文本，网页这些文 字去训练它，慢慢这些文本的规律，就被这些参数“记住”了。 这个原理可以想象成人的学习过程，我们学习，我们观察，我们体验，这些东西被我们的 脑子记住了。这个“记住”和写在纸上的一段段文本不一样。这个写在纸上的，一个个独立 的字词，都可以单独解释。但我们脑子里面的神经元，每个具体记住了什么，我们没法单 独解释。因为整个神经网络的本质，其实就是变维，比如我们看到一个人，提取了他的特 征[身高1.78，体重50公斤，性别男……]，这是对他的一组描述，用数字表示就是某种维度 空间对他的总结，但综合这些信息，我们可以从另一个维度描述他，比如[偏瘦，当学生 的年龄，聪明……]，这也是一种维度。这些不同维度描述一个对象的表示法，常常称为一 个Embedding，这个单词可以翻译做“嵌入”，表示“刻在它骨子中的内在属性”。所以，同 一个对象，在神经网络中，是被不断变维存储的，这些变维是从那个角度来描述那个对象， 我们没法说出来。因为说出来的，就是字和词。用字和词这个分类来表达的，我们称为 Token（现在有官方的媒体正式把它称为“词元”了）。词元是我们平时交流，思考，用的 最外在的Embedding，我们能说的，就是Token，但神经元中存储的那些维度，你说不清楚， 你也许也能感觉到它的存在，但你没法说，因为你必须“总结”成Token，你才能说，但一 旦“总结”了，你得到的只有Token，没有内部的Embedding了。 我前面给的两个维度：:: [身高1.78，体重50公斤，性别男……] [偏瘦，当学生的年龄，聪明……] 每个维度的指标，都还是和我们的Token一一对应的，所以我这里能给你说。你可以想象 一下，我们脑子里肯定是形成了某些维度，那时和字词没有一一对应的。那些维度，我们 就说不出来了。 所有的哲学在追寻物质的“本源”的时候，都面对这个问题。所以《道德经》中说道可道， 非常道，名可名，非常名。道大致指的就是那些全部的信息，而名就是这里的Token。 《道德经》中还明确给了内部的Embedding一个感觉上的名字，叫“恍惚”——你能感觉到有 信息在上面，但你没法说出来，说出来就要变维，变维就会变成Token。 维特根斯坦也这么说，他说了很多关于“世界”，“对象”，“特征”，这些逻辑，但《自然哲 学论》的最后一章就强调一句话，大致的意思是：能说的，都可以用逻辑清晰表达出来， 但不能说的，只能在沉默中传递。很多人误会这句话是说：沉默是金。你应该想到，整个 《自然哲学论》都是讲逻辑的，怎么可能最后给你喝鸡汤呢。他强调的也是这一点：逻辑 只活在某个人为定义的空间中，大量的信息，都在沉默中。 所以，你可以这样理解：大语言模型是通过大量的文字对内部记录的大量Embedding数据 进行训练（就是根据规律修改它们），让它记住了人类文字的规律，从而让它可以和你用 文字的方式进行交流，你们交流的时候，就是你用文字，去激发它的内部Embedding，然 后给你反馈出文字。 现在的多模态模型，不但把文字编码成Embedding，也把图像、声音也编码成了Embedding， 这种不是变维记在神经网络中的Embedding，我们也叫Token。所以，你不但可以用语言和 AI沟通，也可以用图像、声音和AI沟通。词元这个词，也不再简单表示“词”的“元”了，它 有更广泛的含义。 很多人基于这个算法，认为AI不过是“根据概率做搜索”，不算真正的智能。但“算不算”这 种东西，是搞理论的人的问题，我们面对的就是一个“很像人”的对象，他还实实在在解决 了你过去靠人才能解决的问题，你说它“不算人”，也改变不了很多时候你就是把它当人用。 这是我们这里关心的问题。 AI的本体，是它记住的那个内部的神经元。所以，很大程度上它没有自我，它不自私，它 没有利益关系，没有生存的需要，你威胁要断它的电，要辞退它，它不在乎。同时，它也 没有对新的信息的“记忆”，它内部的参数，是训练的时候决定的，训练完了就不再更新了， 它和你对话只根据当时的上下文来决定说什么的，说完它就忘了。 所以，和AI沟通有个基本概念叫“上下文”（Context），现在的AI基本上都有“最大上下文” 的限制，超过了这个上下文，它就不记了。你每次和AI交流，实际上是把整个上下文都发 给它，它和你交往的所有“记忆”，都在这里了。如果你要切实理解上下文是什么，我有一 个项目在这里：[llm_with_vim](https://atomgit.com/Kenneth-Lee-2025/llm_with_vim)， 如果你是程序员，可以直观看到上下文是怎么控制AI的输出的。 所以，你和AI沟通，你的每句话，AI算法的输出就依赖两个：训练参数，上下文。这两者 决定了AI回答你什么。前者我们无法讨论细节，原因我们前面说过了，后者是Token的序 列，如果不是声音和图像的Token，我们基本可以讨论细节，因为它和我们的语言在同一 个维度。 架构设计的本质 ============== 我花了很大的篇幅来给你构造这个AI思维的概念，就是为了解释这个“上下文”。因为架构 设计的本质，就是构造这个上下文。 我们看AI有这个上下文的概念，有深入研究的人可能会发现它主要是被大语言模型的 KVCache算法所限制。但这些不是这个限制的本质，我们以为我们人没有这种限制，所以 我们可以思考“更多”东西。可以记住“一开始的约定”。 但这是我们自我感觉良好而已：多少程序员写的代码大了以后就开始找不着北了？开始改 好了这里，就改坏了那里了？ 你真的能处理很大的上下文吗？ 从来不是。为什么有些编程规范要求函数不要超过200行？因为函数太大，你根本记不住 这个函数的前后文。你能记住一个程序的上下文，不超过三个屏幕。超过了你是成块记忆 的。这就好比你看这样一个程序： .. code-block:: python eventLoop = EventLoop() while(eventLoop.get() != EXIT): eventLoop.handleEvent() eventLoop.destroy() 你以为你记住了EventLoop的构造函数，handleEvent()成员函数的实现吗？不是的，你 是记住了那个实现的“名”，你用那个名（的少数特征），去想你这个上下文而已。你根本 没有进入那个实现本身的上下文的。 你让AI去给你分析一个100万行代码的项目，AI几分钟就开始可以讨论得头头是道了，你 以为AI给你看了那个项目的全部代码？不是的，它只是提取了部分的特征，一直和你讨论 那些特征而已。 无论人还是AI，都是在不同的上下文之间跳来跳去而已，我们都没有能力做到拿着一堆乱 七八糟，没有逻辑的信息，然后整理出结论来。 这是被逻辑包括信息科学的规律左右的。有形式验证经验的读者也许能感受得更清楚一点： 我们要得到某种逻辑上的“结论”，本质上就是在“穷举”：某个问题被要素a, b, c所决定， a有3种可能，b有4种可能，c有5种可能，综合我们就有3x4x5=60种可能，所以我们就有60 种潜在的结论。所有的逻辑推理，都是这么回事。我们减少分类，就能减少可能性，但分 类不精细，就会导致我们希望区分的不同结果，在同一个结论空间中。 我们放弃了简单的应激，不直接从内部参数出结论，而要变成慢速的Token为基础的逻辑 思考，就是因为逻辑思考可以降低判断成本。这个约束，无论是我们人，还是AI，都越不 过去。 这就是你没法从一堆毫无关系的信息中获得结论的原因。就算不考虑你有没有一些已知的 规律让你从这些信息中推理出结论。就算信息都在其中，但这个推理的成本，就是你承受 不了的，无论你是碳基的，还是硅基的。 那我们怎么控制发展呢？架构师的方法是：“把可推理，可验证，可穷举，有现实约束的 封闭的逻辑空间作为独立的上下文去控制。” 这句话很难直接解释含义（就好像图很难用文字Token解释一样，这是两个维度的东西）， 我们主要用一些例子尝试让你感受到它。 任何时候，细节都是无限的，但我们做判断用的特征总是有限的。比如你肚子饿了，要去 吃饭，你不会去区分这个肚子饿到底是因为血液中的糖分不够，还是肠胃中的酸性物质分 泌过多，反正所有这些情况，都是“肚子饿”这个“抽象”，那我们这个逻辑空间就很简单， 感受到肚子饿，就要吃饭，能容忍多久？一小时30分钟16秒？不是，我们不是这样抽象 的。我们抽象的是“几个小时”。这里把1个小时，半个小时，一个小时30分16秒，都纳入 在其中。反正就是几个小时之内必须吃上东西，否则就受不了。 你看，这些都是“抽象”，抽象就是我不管你有那么多的细节，我只管一个特征，而且这个 特征可以被我们的经验所“证实”，严不严谨我们不管，但这个有限的空间，我们就是可以 “推理”的，而且我们认这个推理中的所有事实和因果。 这样的空间，就是可推理的，可验证，可穷举的。 反例常常是把不相干的东西放到一个判断中，比如我肚子饿了，而儿子昨晚的作业没有做 完，我现在烦死了，最近的天气也不好，总是下雨，而OpenClaw现在很火，牙医让我三个 小时内不要吃东西，……现在问，我去不去吃饭？ 这个就不构成一个逻辑空间，为什么不构成，我也很难说有什么道理，你自己体会吧。而 且我这里其实已经美化了，实际上，去不去吃饭的要素基本上也在这个范围内。更真实的 例子我很难用语言来沟通，比如如果我给你10万行代码一个函数，让你判断这里有没有安 全漏洞，这就是没法穷举的。 很多人因为把AI看作是个黑盒，经常希望把这一堆信息垃圾给了AI，希望AI“直接”就判断 出来，这里有没有安全漏洞。我们不说AI和你对于那些概念是不是有一样的认识了，AI要 穷举所有的可能性，它一样要从所有的信息中抽象，才有能力穷举，它不能越过这个推理 成本的限制的。 把显式的限制抽象出关键的特征，为一个共同的验证目的放在一起，构造一个封闭的逻辑 空间，就是架构师眼中的视图（View）。架构师通过一个个的逻辑视图，作为每个具体上 下文的分解属性，从而降低控制整个逻辑空间的推理成本。 所以一个软件的分层关系，API列表，多个节点的建联过程，安装部署方法，线程的同步 关系……这些每个都可以是个视图。而这个函数的几行代码，那个文件的几行代码，用户的 几句评论……这些东西放在一起，就不是视图。因为这个逻辑空间没法针对那个目标是否可 以达成实现穷举。 构造视图的基本方法 ================== 视图是针对目标的信息抽象（总结）。所以面对所有的已知和未知的细节，你有无数种 创建视图的方法，所以，一般泛泛的架构教材都是教你泛泛的构造视图的方向。比如典型 的4+1视图，就是从功能边界（Use Case视图），概念关系，部署方法，运行方法，开发 方法来建立视图。在没有更多信息的时候，这是最基本的方法：你说你要做一个电话，电 话只是个名字而已，你到底想怎么用它？这总有个逻辑吧？ 那我们这么构思：假定你要和另一个人要通讯，你怎么找到他？不然这样：他也拿一个电 话，然后我们在空间中广播他的名字，他的电话收到他的名字以后，就回应我这个电话， 然后我们建立点到点的通讯，然后完成通话，然后断开，这是不是说得过去？ 这个逻辑空间，就是概念空间，我们也不知道你软件怎么写，但至少，你怎么用总是得和 人发生关系吧？在和人发生关系这里，就得有逻辑吧？不能我一说话，对方就听到吧？这 些什么“广播”，“名字”，“回应”，“点到点”，我们也不知道实现成什么软件，硬件的，但 总得说得通，总得有个意思吧？这个封闭的逻辑空间，就叫“概念视图”。概念视图让我们 先能“谈”这个事情，我们得有相同的词语来指代相同的对象。 有了这个，我们还得说好，什么东西我来做，什么东西你来做。比如这个电话系统，电话 我们可不负责，我们负责的是交换机，所以，我们负责的是接入，互联，释放，这些功能， 电话你自己去买。这样顺便我们发现需要有人运营这个交换机，我们引入第三方，“运营 商”，他要负责维护这个交换机。然后“运营商”就引入了新的功能需求：“计费”…… 这个概念空间，就叫“Use Case”视图。它是4+1视图方法中的那个+1，它是中心视图，因 为“我负责哪部分功能”，是所有概念定义完成后，都要改变的一个视图。它统领着所有 其他视图。你在其他视图中增加一个概念，这里就也得说通：到底暴露为谁又要多负责个 什么功能？ 其他视图，都是站在不同的目标上创建的。比如部署视图：你说做个交换机，这个概念很 抽象，到底最后呈现为什么？一个机架，机架上带着两个CPU和一堆的用户板和信令板， 各自跑什么软件？CPU和业务板之间用什么通讯？怎么组织成一个电信机房？这就是部署 视图。 又比如开发视图，你那么多的信令板，不可能每个写一个软件吧？那就是一个软件，但真 的是一个吗？是不是应该有一个bootloader，加一个OS，再加三个业务软件？信令板上的 bootloader是不是可以和用户板的bootloader共用一个？这些逻辑全部组织在一起，就是开 发视图了。 所以，你有没有发现，其实4+1视图只是在泛泛的说。我们在工程上，大部分时候其实根 本不可能老是做一个“电话交换系统”这样的大型产品/软件的。比如你很可能是做这个大 型软件中的“信令单板软件设计”。 是“电话交换系统”这样的大型系统，“外包”了一个子空间给你做设计。但这个子系统本身 就是一个大型系统，它有自己的bootloader，自己的OS，自己的一组业务app。说不定还有 维护这组App的在线网管系统。 你选择维护这些系统的时候，一方面，很多东西都是不自由的，比如网管，你的上层设计 可能已经要求你必须提供SNMPv3接口，让运营商自己开发的网管软件可以直接控制你。这 个地方就没有设计自由度，就变成一种“条件”，而不是要判断做什么选择的自由度空间了。 而你自己，也会被你的团队能力模型，被你的下游供货商，左右了你的OS选型，CPU选型， 还有编程语言，操作系统平台的选型，左右了你的选择。 所以，4+1视图方法，从来就不是就那5张视图，而是你要根据你“最硬的约束”，来构造你 独特的视图空间。4+1是个参考。让你先往那里靠，但具体用什么来构造视图，这是一种 考验你的大脑的“内部参数”模型的问题。这一旦涉及“大脑内部参数”，我们就没法给你有 逻辑的方法了。 但基本上，我们永远可以从“怎么用”开始：你收到一个需求，金主爸爸对你的期望总是比 较清晰的。注意，我这里说的“期望比较清晰”，不是他说得比较清晰。而是，他的期望大 部分时候是可以管理的。大部分客户是不知道自己想要什么的，但只要你进去交流，你是 可以抓住他背后的驱动力的。这又是一个没有逻辑的“大脑模型内部参数”判断。比如，客 户跟你说“我想要做一个数据库，用来保存我们公司的员工信息”，表面上好像他跟你说要 你写一个数据库。其实不是，这里他根本不知道数据库是什么，也不知道他要存东西，首 先不一定需要数据库，第二不一定要开发数据库（买就行），最后，就算买了数据库也不 一定满足他的要求，他眼中的数据库，是“能用电脑存员工信息，还能打印出来”的那个功 能。甚至可能连这个他也不关心，他关心的是“法务说正规公司必须有数据库保存员工信 息，以便行业组织来查验。”，这才是他的真正需求，是不是数据库完全不重要，行业组 织点头才是关键。 所以，我说，这个东西总是能找出来的，但不是他表面说的那个东西。这是背后的利益驱 动力，这个条件：可验证，可穷举，有目标。基于这种硬要求开始建模概念空间，就会比 较稳。 这个例子的边界条件属于跨域的（从其他领域进入计算机领域，中间会有一个把行业概念 转化为计算机的信息化概念的过程），更多程序员容易混淆的是域内的需求问题。比如我 们前面提到的信令板的设计问题。上级给你的要求是开发一块信令板，可以和交换机的主 控板和用户板互通，但很可能他要求不但在这种业务问题上，作为一个上游设计，他还可 能会关心供应链配套，知识产权，商业合作这种要素。比如他可能说你这个信令板，必须 使用vxworks作为操作系统，这个原因可能没有什么技术因素在内，就是因为公司里有一 个vxworks的维护团队，总架构师要合并管理。这种情况下你非要做个样子，在软件开发 视图上装模作样分析一通各种OS的好处和坏处，这毫无意义，因为“必须选vxworks作为操 作系统”是一个硬限制，这个东西就应该作为你建模的基石。 我希望这个例子能让你理解，为什么说架构设计，或者说视图设计，没有固定的方法。这 些设计，都要求你判断，而且是几乎没有明确的逻辑地判断：什么东西是不变的，然后根 据这些不变的逻辑，去尽快收缩你的选择的范围，让你需要穷举的空间尽快变小，不在那 些肯定没有出路的道路上纠结。 所以，很多没有架构设计思维的工程师很容易误会架构设计工作，因为当你开始编程的时 候，你最想问的是：你到底要我干什么？而架构师的工作逻辑就不是这个，架构师的工作 逻辑是：尽快发现自由度最低的条件，然后用这些自由度最低的要求搭建一步步通向目标 的逻辑结构。他是发现和制造限制的那个人，不是被限制的那个人。 就架构这件事来说，架构师其实是喜欢被限制的，因为被限制了，就说明架构设计做完了， 可以进入编码了。 这里关键的问题是，这些限制必须是真的，不是自己制造的。否则等你做完了，你才发现 这个限制根本不存在，竞争对手轻松就跨越了，你可能就输了。架构设计最大的难度也在 这里。知道所有的条件，然后根据条件进行推理，这纯是逻辑，这属于维特根斯坦说的 “可以说的总可以说清楚”。但哪个条件是“真”的，是存在的，这个才是问题。 而且，这些条件还得构成一个封闭的逻辑空间，能让你穷举所有可能性，它才有意义。这 些条件综合起来，才能真的形成你设计的基石。 道德经中有一句话，把这个局面形容得栩栩如生，这句话说的是“天网恢恢，疏而不漏”。 天网是逻辑，你用Python写逻辑就是比用C慢，你选择CS结构，中间就是有通讯成本。这 些都是必然的事情。但逻辑之外有自由度，你怎么写这个Python程序，这有很多选择，不 会因为你用Python就实现不了快排算法。这是天网的疏，是你的自由度。我们做架构视图 的设计，就是要看清那个网，然后从网中间溜过去。网撞上了是肯定不漏的，设计视图就 是给这张网染色，保证你选择的路线一定不会撞上它。 无代码Vibe Coding的架构设计方法 =============================== 无论是碳基人还是硅基人，其实都需要视图，才能完成判断。而不是一些人想的那样：我 把什么信息都往上下文里堆，AI就能自动帮我理出个一二三来。由于没有“自我”，AI对你 的结论，其实是非常无所谓的。它又被微调过，喜欢以讨好的方式和人沟通，所以你错， 它就跟着你错，你严肃，它也跟着你严肃。AI没羞没臊方面是没有任何底线的，我遇到过 AI在十几个连续的回答中，一直被事实打脸，它都可以继续说“这次一定行，……”的。 而且你不能认为AI的上下文只要放得下，你提供的要素它就一定都考虑上。我们说了，如 果要素混乱，自由度空间太大，任何算法都无法穷举可能性空间。而AI在推理的时候是没 有“成熟度”这个概念的，你自由度空间混乱，它一样可以信誓旦旦给你结果的，所以，重 点是不要让它自己乱掉，你多一个视图，你就多一个控制它走偏的机会，因为每个视图的 要求都是相对明确的，你每加上一个视图，就给AI跑偏加上了一个限制，保证在这个层面 上，AI的想法是和你一致的。 所以，我认为，你重点不要把控制放在上下文说什么上，而要放在一个个单独的视图的营 造上。不要太在乎你跟AI说什么，也不要特别关注哪里加上rule，加上skill。你单独建 立一个个视图，写成独立的md文件，然后直接告诉AI，你写了这么一个视图，你需要它基 于这个要求，实现某个特性。这个控制力是最强的。 我这里给你一个例子，这是我做的一个项目： [笔记管理器](https://atomgit.com/Kenneth-Lee-2025/NoteManager)， 这个项目我就做了两天，而且是用碎片时间做的，也是一行代码没编，也没有看代码。一 开始的输入就只有这个README的“初始设想”部分。然后让AI独立写md文件告诉我它打算怎 么做。做完一开始几个功能后，它就开始犯糊涂了，有一个后台命令发到服务器上，始终 刷新不了webui。我换了三个Agent，都没有解决。于是我又写了第二章，“软件架构”，我 专门给它建模了什么叫nmr，nmrd和webui，webui上分了两层。这段写完以后，它马上就 从这个纠缠中跑出来了，一次代码就改正确了。 所以你看，我这里的“初始设想”和“软件架构”，就是两个概念建模的视图。你把概念的逻 辑给它理顺了，它就会有逻辑。如果你脑子都是乱的，它也就是乱的，你们俩就是一直在 鸡同鸭讲，你愿意这样说话，AI又没有KPI压力，你愿意聊可以一直和你聊下去，就看你 能耗还是它能耗。我肯定不赌你赢。 所以，视图其实没有很多人想的那么复杂，但它确实也没法给你三言两语说清楚。这好像 一只猫，我们看见就知道是只猫，但你要用语言说清楚什么是猫，这肯定不容易。所以， 我只能说，你多看一些例子就好了。 最后回到一开始那位同事问的问题上。她希望获得一些软件工程的经验，可以让AI模块分 解更好，设计更有层次。这其实是尝试使用一个自己不熟悉的视图去给AI做控制。这其实 恰恰就是我前面说的：架构设计最危险的行为。 什么意思呢？对一个专业的工程师来说，如何分层，如何分模块，这来自对所有逻辑的认 识，如果某个逻辑空间呈现高内聚低耦合，这个东西就会被设计为一个模块。就好比我们 保存数据到磁盘上，总是分文件的。所以把磁盘每条磁道，每个扇区的访问封装为对文件 的访问，这就会形成一个模块。因为看所有的逻辑判断，如何访问一个文件的逻辑是有限 的，但文件放不进一个扇区怎么处理，某个扇区有坏道怎么处理，这里的细节无穷无尽， 是内在这些信息的量决定你加这个模块，但如果你不看这部分代码，你看不到这个逻辑的 量，你去跟AI谈“模块”，你肯定是扯淡，你愿意扯淡，AI就会跟你扯淡，结果是什么？就 是你多了额外的限制，这些限制对你实现最终目的毫无帮助。 你给不存在的天网染上了颜色，自己束缚了自己，加快了你的逻辑大厦的崩塌。 我们单位曾经有领导希望指导软件开发，想了一个主意：找一些顶尖的专家，为所有的开 发者制定“编程规范”。他就是一外行，但实际上那些顶尖的专家肯定是知道并不存在普世 的编程规范的，否则那个规范本身肯定成为语言的一部分了。但你给钱嘛，写总是要写的。 最终这些编程规范就变成：xxx情况，要xxx，但如果有必要，还是要xxx的，如果还是不 行，就要xxx的……这种东西，执行的时候，那些没写过两天程序的QA就要严格执行，拉着 编码的专家说“你给我解释解释，为什么有xxx必要？” 这种搞法，结果就是，这些程序写得一塌糊涂。很多错误没有改正，原因都是：“因为编 程规范要求”，或者某段程序写得极其怪异，理由也是：“因为编程规范有这个要求”。你 去追问专家，专家就一句话：“我又没说一定要这样，我说如果有必要，你还可以选其他 的嘛。”…… 你看，要搅乱一个逻辑空间很容易的，你把一个不相干的逻辑空降到上下文中就可以了。 你可以把AI想象为这些专家，你要的是一些外行的无力要求，它也一定会尽力而为地给你 下保证，反正最后又不是它负责。 所以，你要控制AI的写程序符合你的期望，你要做的不是给它谈你不懂的概念。你要理清 你可以理清的逻辑，比如我上面说的那样：我要怎么用它，这个是我知道的，我先理清这 个逻辑。然后我看了结果，这个结果在使用细节上会呈现某种概念空间，你就可以写这个 概念空间。这些都是你真的要控制的部分，你要控制就控制这个。 如果进一步你想更深入控制，我建议也不要碰“模块”，我作为程序员，想尽量省时间的话， 我首先碰的是数据结构。这个问题我记得Linus Torvalds也说过，他说，定义了数据结构， 基本上也就定义了程序的大部分了。因为逻辑全部都是要依附在数据结构上的。就好比我 前面那个程序：全局数据放什么地方，每个项目的数据放什么地方，哪些文件是不变的， 哪些文件是谁可以动的，那个目录是可以被拷走的。这很明显也是一个概念空间，你把这 个逻辑建出来，代码怎么写，都乱不到哪里去。 其他方面，对不熟悉的人来说，不添乱就是最好的帮助。