1. LLMs的能力边界
主观认识： LLMs是通过大量数据训练的“语言模仿专家”，其原理是基于概率的文本预测模型，输出结果具有概率性，无法保障100%准确。但是在专业人士的引导下，可以将信息处理、语言理解的效率提升数十倍，核心强调增强而非替代。
1.1. 适用场景
信息摘要与知识整合
创意辅助与内容生成
- 场景示例：营销文案、代码生成
- 优势：提供多样化创意选项(如一次生成10条广告标语供选择)。降低投入在重复性的编码工作、技术细节上的时间。(需要专业人士监督)
- 相关产品： copy.ai、cursor、cline
流程自动化与效率工具
个性化教育与学习
1.2. 局限性
需要高精度和低容错的任务
- 场景示例：医疗诊断、金融交易、航空控制。
- 局限：LLMs的生成结果具有概率性，倾向于近似而非精确计算，可能包含错误或模糊表述，无法保证100%准确性。(需要专业人士进行审核测试，或者以专业人士为主LLMs进行辅助)
需要深度逻辑推理或数学计算
- 场景示例：复杂数学证明、工程仿真、算法设计。
- 局限：LLM擅长模式匹配而非严格逻辑推导，可能出现“自信的错误”，并且多步骤推理中错误会累积。(随着模型的优化此类问题已经在改善)
要求高实时性的决策系统
- 场景示例：自动驾驶、应急系统。
- 局限：此类系统需要毫秒级的做出反应，LLMs的处理速度和可靠性难以达到要求。
依赖实时信息的任务
- 场景示例：突发事件报道、交通调度、股票市场预测。
- 局限：LLM的训练数据(记忆)具有时间滞后性，无法获取最新信息，目前通过RAG技术可以补充实时数据(具有检索相关性、准确性的挑战)，但是处理信息的效率受限于上下文长度，并且超出上下文窗口的信息回被遗忘。
2. 我能用LLMs做什么
主观认识： 核心是拓宽了人的能力边界，当对LLMs的使用方式有了足够清晰理解，再加上对现实世界问题的洞察力，就可以构建出原本个体无法独自构建的产品。
2.1. 自然语言编程
AI前沿科学家Karpathy2023年的主张，虽然现在自然语言编程还未成为实质上的新抽象层，但是其积攒的势能已经难以阻挡，只是最终的形态还在发展过程中。
- 更深层的含义： 我们能否使用自然语言将一件事情完全讲清楚？ (前提是先想清楚)，当越来越多的工程师能够用自然语言生成高质量的代码后，这个事实标准就会逐渐形成。对于无法做到这一点的工程师来说，就好像你写的代码编译失败是人的问题，而非编译器的问题。
- AI编程工具引起的5点变化：
-
- 提升个人理解和表达能力： 过去的技术方案与代码之间，会有一定程度的信息差，因为有些信息是随写代码的过程思考清楚的。而现在要求在写代码之前就想清楚，并且通过文字表达清楚。
- 更多的时间专注架构细节： 从主动的视角看，因为我们要想的足够清楚，这个过程自然而然的会发现一些问题，并且微小的改善可能只是增加一些文本描述。从被动的视角看，当AI能够完成足够多的编码工作，人要证明自己的价值就需要找到一个新的出口。
- 提升软件工程质量： 从短期看由于选择的LLM模型能力差异、个人水平差异、文档不完善等因素，可能工程质量是下降的。但长期我个人是持乐观态度的，当我们有足够完善的文档和好的使用习惯，AI会完成人类程序员不愿意去做的事情，比如单元测试、修复一些微小的BUG、编码风格等。
- 更多的软件化诉求： 随着编码本身的成本加速降低，那些当前潜意识认为没必要写代码完成的事情会变得有性价比，当足够多的人慢慢意识到这一点后，对软件化的诉求会有大幅度的增长。(以及AI编程已经逐渐在产品化，下文会有我个人的延伸思考)
- 新项目的快速学习： 随着人类工程师与AI对项目memroy的双向完善，学习一个代码仓库的速度会大幅度加快。
2.2. 提升学习和生活质量
我个人主要的观点是要认真的对待学习和家庭，在这其中识别能够提升幸福感的微小事情，为这些微小的事情编程。(在AI编程之后成本会变的特别低，这个过程本身可能也是乐趣）
- 学习的幸福感： 比如个人学习中需要与AI工具频繁对话，需要收藏一些高质量的回答，或不理解的名词追问，可以通过开发浏览器插件的方式，一键收藏到个人笔记、一键追问。
- 老婆的购物幸福感： 比如老婆喜欢去国外的独立站购物，可以开发一些小工具按照家庭尺码进行转换等。
- 小孩的游戏幸福感： 比如将小孩天马行空的想法变成一个小游戏，并且可以根据小孩的想法灵活调整。
2.3. 集成到商业系统中
将LLMs集成到商业系统的案例已经非常多，此处就不再过多的赘述，主要是思考下集成LLMs的应用和传统应用之间要重点关注的差异。(在确定性系统中引入了非确定性引擎)
- 建立评估系统： LLMs本身是非确定性系统，需要一个系统性的方法衡量系统接入LLMs之后的准确性和可靠性，例如使用不同模型和Prompt时相关性、幻觉等关键指标的评估。并且这个过程要作为软件开发生命周期中必要的环节，各项指标需要达到预期准确率才可以发布到生产系统中。
- 怎么识别LLMs出问题了： 虽然有了前置的评估方法，但是由于数据局限性、用户行为的变化等因素影响，仍然需要定义在系统运行的过程中的错误指标，LLMs的输出了哪些信息则认为系统出问题了，收集上下文数据并告警。
- 新的系统监控指标： 需要定义与LLMs相关的系统监控指标，如首Token延迟、每秒生成Token数量、吞吐量、超时率、错误率等，并且需要针对Token花费重点关注，避免LLMs死循环后产生大量成本消耗。
- 明确的业务指标： LLMs本身无法做到100%，需要针对业务场景找到关键的业务成功指标。如聊天机器人中人工干预率低于5%、销售机器人转化率达到10%等。
3. 怎么用好LLMs
主观认识： 把LLMs当成一个高智商+拥有密集知识的实习生，但是要记住这个实习生一次只能记住200k的信息，并且做的事情不是100%准确的，需要你把事情讲清楚的同时，也需要对其工作结果进行检查。
3.1. 问题的理解和表达
在让AI帮你做事之前，要先问下自己对于这件事情，自己是否已经想清楚了，并且将想清楚的事情先写在文档中(当然也可以让AI给出建议去完善)。
- 问题的清晰的理解： 我的原则是当某一个环节我自己的理解还存在模糊的时候，就需要揪着这个地方先让自己完全理解清楚或想清楚。
- 一句话生成xx本身是自媒体的流量诉求： 在真实复杂的生产环境中，完整无歧义的表达是必要的，只有这样才能稳定的获得可在生产环境直接使用的内容。
- 信息的传递理解的损耗： 我个人倾向于一次将较为完整的上下文给到LLMs，因为每次的对话中的传递->理解->输出，都会存在信息的损耗和准确率，当多轮对话叠加后很容易出现偏差过大的结果。
3.2. 持续关注上下文水位
LLMs的上下文大小，就像回到了只有1M内存的计算器时代，怎么让一个冗长的程序要运行在这个1M内存中，就需要足够的技巧，在LLMs真正解决这个问题之前，这个技巧本身就具备商业价值。
- 速度影响： 过大的上下文，意味着消耗更多的计算资源，上下文越大速度也会越慢。
- 注意力影响： 过大的上下文会争抢注意力，太过分散的注意力会降低输出的准确率。
- LLMs训练原理： 微调对话中大多数训练数据都比较短，并且在人工数据标记中，对一个大型会话标记什么是最佳回答，本身也不太现实。(来自Andrej Karpathy的x)
3.3. AI编程工具的一点使用心得
思考AI程序员需要什么技能：能够在LLMs 200k的上下文限制下，完整的开发一个复杂的项目，其中AI代码可用性达到90%以上，并且消耗调用次数不超过n次。如果达不到这个要求，就需要反思下是不是上面的两个地方哪里做的不好。
- 选择哪个工具： 我个人是Cline、Cursor都有在使用(还有阿里内部Copilot)，在这个领域飞速发展的阶段，核心还是要理解设计理念，其之间的根本区别不在于技术能力，而是如何看待人类工程师与AI之间的关系。比如Cursor像一个编程助手，使用起来性价比高，但是要自己完整的讲需求将清楚。Cline像是工程师合作伙伴，显性化的plan模式，先和你一起将一个需求讨论清楚，再写代码，但是成本更高一些。(好玩的是在cursor中可以安装cline)
- LLM模型的选择： plan使用DeepSeek-R1，act使用claude。(claude是目前公认最强编程模型)
-
- Claude：可用性最强、速度中等、成本高
- DeepSeek：可用性中等、速度慢、成本最低
- Gemini：可用性低、速度快、成本中
- 构建代码仓库的Memory： 在开发过程中完善代码仓库的Memory，将从架构、技术栈、编码规范到不同模块的作用，逐渐积累出整个项目的文档，在前期可能需要额外耗费一些时间(可以让AI辅助生成)，随着文档完整体的提升，使用AI编程的效率和代码质量会随之提升。(以markdown格式写的文档，对不同的AI编程工具均可适用)
- 像使用内存一样使用上下文： 就像电脑虽然有16G内存，但是你完全用完的话电脑就死机了。在确保表达清楚的情况下，保持一个健康的上下文水位(60%)，避免LLMs注意力分散导致准确率下降。
- 使用结构化的方式表达需求(.md)： 将需求拆解为小型的内聚模块(足够一次装入上下文)，并且使用markdown文档描述需求，而非零散的对话，必要的时候使用伪代码或Mermaid图，这会让上下文更加准确和聚焦，可以显著提升生成代码的准确率。
- 设计到UI的功能提供交互稿： 自然语言对交互的描述会存在比较大的信息差，比较可行的方式是提前通过工具生成交互，再将交互作为上下文给到LLMs，生成的前端代码准确性会更高一些。(金钱换来的经验)
- 设定规则界限： 针对一些高确定性、零容错的核心文件，可以设置规则进行保护，让AI不要操作这些文件，避免被AI无意中修改引发重大问题。
4. 对未来的一些想法
4.1. 全力使用AI
个人观点(谨慎采纳)： 现阶段就像处在计算机革命和移动互联网革命的初期，新兴的技术可能还不够成熟，使用起来比较痛苦，但是这些痛苦可能就是未来的商业机会，要生活工作的方方面面入手全力去使用、感受。
- 从主业出发： 比如我是程序员，我自己则是从编程这个核心技能出发去深度使用，将自己现有的认知与新兴技术的设计理念碰撞，形成对新兴技术的个人观点和使用习惯，以自己这个最初的观点再持续迭代加深认知。
- AI融入生活： 在新兴技术与现实世界融合的过程中，会改变生活的各个方面，目前生活中的痛点，很可能也是未来的商业机会。
- 分享和交流： 在一个新兴技术快速发展的过程中，自己学习心得的分享和交流是非常关键的，找到能够理性客观交流一些小伙伴，定期交流新的认知和有趣的发现，是修正和加深认知很关键的步骤。
4.2. 软件开发的局部产品化
个人观点(谨慎采纳)： LLMs的主要优势就是处理文本，编程语言本身也是文本，而编程语言和自然语言相比，其语义会更加清晰明确，很适合做为LLMs到一定确定性产品功能的桥梁。如Claude生成的图表、Manus等都是为一件小事写了一段代码。
- AI编程成为基础设施： 从这个趋势看，编程工具这个生产力工具与产品功能基础设施之间的边界已经在逐渐模糊，AI编程也很可能会逐渐成为商业产品的基础设施。
4.3. AI产业的泡沫
个人观点(谨慎采纳)： 我认为AI可能会经历类似互联网的发展路径，包括泡沫增长与泡沫破裂阶段。尤其是当前(2025年)我们可能正处于AI热潮阶段，类似于1999-2000年的互联网泡沫顶峰。但是AI作为一个革命性的技术，未来同样可能会出现和互联网一样，在泡沫破裂后再次回归理性稳健发展，最终成为真正的基础设施。
4.3.1. 互联网发展历程
互联网的发展大致经历了以下阶段
- 萌芽期（1969-1990） ：从ARPANET到早期互联网，主要用于学术和军事领域
- 商业化早期（1991-1995） ：万维网出现，初步商业应用开始
- 热潮与泡沫期（1995-2000） ：大量投资涌入，互联网公司估值飙升
- 泡沫破裂（2000-2002） ：互联网泡沫崩溃，大量公司倒闭
- 稳健发展期（2003-2010） ：Web 2.0兴起，商业模式逐渐成熟
- 移动互联网时代（2010-至今） ：互联网深入社会生活的各个方面
4.3.2. AI发展历程与预测
AI的发展经历的几次浪潮
- 早期探索（1950-1970） ：从图灵测试到早期专家系统
- 第一次冬天（1970-1980） ：投资减少，热情消退
- 第二次浪潮（1980-1990） ：专家系统再次流行
- 第二次冬天（1990-2000） ：期望落空
- 深度学习崛起（2010-2020） ：技术突破，应用拓展
- 生成式AI热潮（2022-至今） ：ChatGPT等大型语言模型推动新一轮热潮
- 泡沫破裂（未来） ：大量将AI当魔法盲目采用的公司倒闭
- 稳健发展（未来） ：AI技术趋于成熟，商业模式成熟，深入到社会生活的各方面
以你现在的认知和阅历，如果站在2000年的时间点，你会做什么？
