---
title: "正确的使用方法"
date: "2026-02"
category: "ai运用"
tags: ["ai运用"]
description: "我觉得运用LLM的关键点是让自己跳脱出单纯的写代码这样的固化思维——将自己作为一个规划任务的主管，或者是微操大师去监察任务，而不是单纯的让自己成为一个局外人..."
source: "https://enriquemark.com/zh-hans/posts/%E6%AD%A3%E7%A1%AE%E7%9A%84%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95"
---

我觉得运用LLM的关键点是让自己跳脱出单纯的写代码这样的固化思维——将自己作为一个规划任务的主管，或者是微操大师去监察任务，而不是单纯的让自己成为一个局外人。这一切都建立在对项目和设计、架构、技术的理解之上。我的确可以不懂所谓的「具体代码」怎么实现，但我必须关注「输入」了什么，以及「输出」了什么，其次则是「安全」与「性能」。作为技术主管，我当然需要对我要求员工使用的技术，至少有足够的了解。

小模块，精确的提示（明确的指向特定函数模块以及操作逻辑，这本身就需要人类对项目的理解），架构设计——可以避免完全交给ai带来的上下文缺失和维护地狱。尤其是要以vibe工程的思维来考量，测试和谨慎也必不可少。

今天的debug的经历是很有意思的，完全的把问题仍给ai并不能解决问题，最后还是我自己找了半天，做了断点测试，把问题源头定位出来，明确的给了指令让他去修复——而且一开始居然给了一个很复杂的重构方案明明只要出口封装一个str输出就够了，他却跟我说要把三个模块重构才能才把问题解决，这明显是一个问题。

而且有一点我的确是赞同的，用ai的时候会给人一种虚假的掌握感，一旦遇到了ai解决不了的问题就会无助，甚至是焦虑和愤怒。尤其是ai写的代码我几乎看不懂的情况之下，这就非常成问题。所以对业务逻辑和项目的理解是至关重要的，所以我认为最谨慎的ai应用方式就是明确的指定「应该如何，以及用什么方法写」，精确到类是最好的。他的确不如直接全部交给ai要来得那么快，但也至少提升了百分之二三十的效率。尤其是考虑到未来可能遇到的维护地狱，人工设计的结构是建立在对项目的充分掌握之上，因此出问题至少不会毫无头绪。ai有些时候会对错误进行过于完美的包装，导致出现问题都不知道到哪里去定位，因此测试和可维护的设计非常重要。

Bash非常灵活，可以借助此而调用已有的命令行功能。