立正提到，判断一支团队成败，不能拿整个愿景是否实现当唯一标准，而要看能不能持续交付对业务有意义的里程碑；而且这些里程碑要事先和上级谈好，哪些结果算达成、哪些不算，不能等到年底再解释⁠1。放到你的处境里，成员“表现欠佳”可能不是不努力，而是他们不知道下一次用什么结果证明自己在往前走。可以先挑一件正在拖的事，把“做完”改写成两三个可验收的小结果，比如谁在什么条件下交出什么、给谁用、怎样算通过。观察成员接到这种具体结果后，是仍然不动，还是开始有动作——这能帮你区分是意愿问题还是目标模糊。

立正说，只给下属负反馈、只管理动机，并没有真正从工作角度帮他把事情变得更容易或更有效；他把这种欠缺的能力拆成自省和把隐性知识显性化两块——任务不达预期时先反思自己的问题，再把自己心里那套做法讲成别人能照着做的步骤⁠2。成员“动作变形”可能正卡在这里：你以为说清楚了，他们拿到的只是模糊要求。可以选一个反复出错的环节，你自己先做一遍，把判断依据和步骤写下来给对方对照，看变形是否减少。若减少，说明缺的是显性化的方法；若照做仍拖延，再去看动机和负荷。

立正反对把路线图做成一份详尽的交付物清单，因为团队会把这些交付物本身当成目标：有人花一天打磨文档格式却没跟一个真实用户聊过，有人把看板上的任务全部勾完，产品是否成立依然没有答案。他主张每一阶段的里程碑是一句判定标准——这一阶段结束时，能不能用证据而不是感觉回答这个问题；答不上来，这一阶段就算失败，不管交了多少文档。所以拆大目标时，先问“到这一步我们要能拿出什么证据”，再倒推要做什么，而不是先列任务再排期⁠1。

团队不认里程碑，常见原因是只听到一个大目标或一个好听的项目名，不知道自己具体负责什么、最终要交出什么实实在在的成果。立正讲跨团队合作时强调，要明确自己做什么、需要别人做什么，这样上级才好判断贡献、协调资源。放到里程碑上，就是每个节点都写清谁交付、交付什么、依赖谁；成员看到自己的那一段被算进去，才会把它当成共同目标而不是上面派下来的任务⁠2。另外，提问时留一个口子让对方检查你的判断，也比直接宣布拆法更容易得到真实反馈：可以说清自己为什么这样切分，再问这个理解是否成立、有没有更该先解决的问题⁠3。

如果大目标背后的判断错了，拆得越细，团队越可能整齐地走向错误方向。立正遇到创业者问怎么推广时，先追问的是收费方式、客户为什么付钱、竞争优势从哪来，因为这些问题没想清楚，给一套推广方法也用不起来⁠3。同样，一个维修平台如果把精力放在让 AI 生成更漂亮的清单，而客户真正买的是按时干完的交付，里程碑就会优化错地方⁠4。拆之前值得让团队一起回答：客户或上级真正要的结果是什么，我们靠哪项能力持续提供它。

立正提到，很多公司宣称自己 AI 用得多、每天消耗多少 token，但被问到销售额和利润有没有增加时，答案往往模棱两可，看不到“用得越多赚得越多”的明确关系⁠1。所以 80% 的冗余额度只是产能，不是收入。真正决定能不能赚钱的，是这些产能有没有落到一个具体需求上：比如某个小组织每月已经在为一件简单的事付费，你用额度把它做出来，才谈得上变现⁠2。

立正用一周密集使用 AI 额度搭社区基建的经历说明，AI 把执行速度提上去以后，瓶颈转到判断和架构上，而且最有用的工作常藏在最后 10%——付款能不能走通、权限会不会发错、手机上能不能用⁠3。他给的标准很朴素：这周有没有做出一些真正有人能用的东西⁠3。放到你的处境，与其想“怎么把额度换成钱”，不如挑一个你熟悉的小场景，用额度做出一个别人能直接用的成品，再拿给一两个真实用户试。他们愿不愿意继续用、愿不愿意付一点钱，比你自己估算额度值多少钱更能说明问题。

立正讲过一个例子：有人发现一个每户收两块钱、管三百户的小软件，觉得自己一周就能做出来，但马上又担心别人用更便宜的方式取代自己，于是决定不做了⁠2。这种担心在逻辑上成立，但它发生在做出任何东西之前，等于用想象中的竞争替自己做了放弃的决定。更实际的做法是先把第一版交到那个具体客户手里，用对方的反馈判断值不值得继续投入，而不是在脑子里推演所有替代方案。

立正区分过“名词”和“动词”：名词是能收藏的概念，动词是真正把事做好的动作，而动作的差距外人很难看见，只有走过这条路的人才能指出来⁠1,2。所以动作层面的细致教学并不多余，反而是稀缺价值。问题出在你把判断也一起教了：该由他权衡的取舍、该由他承担的后果，你替他决定了，他自然不用琢磨。可行的分法是：动作示范到他能复现，判断只给边界和判断标准，具体选择让他做并承担结果。

立正主张不要用交付物清单当目标，否则团队会打磨文档格式而不去验证真问题；每一阶段应该用一句话说清“结束时能用证据回答什么问题”，答不上来就算这阶段失败⁠3。这正好能解你的矛盾：动作教细，但验收点设成需要他自己判断的问题。比如不检查他有没有按你的步骤做，而让他说明这一步为什么这样选、如果换一种做法会怎样。他答得出，说明琢磨发生了；答不出，你再补动作细节。

立正也讲过做事效率：不要先讨论半天，直接上手做，做到被卡住再去找人，比先讨论再动手快很多⁠4。对应到带人，你可以要求他先带着自己的尝试和排查结果来问，而不是带着空白问题来。他提问时把思考负担留给对方，说明他没自己琢磨；带着具体尝试来问，说明他琢磨过了，你只需补那一段差距。

立正区分过“做出来了”和“学会了”：AI 直接给出结果，过程被跳过，分数可能一样，但能力没长。他给的检验是撤掉帮助、隔一段时间、换一道没见过的题，你还会不会。所以关键不在今晚玩不玩，而在你学 AI 的那段时间里，是不是只看了教程、让 AI 跑出结果就以为会了。如果学习方式是后者，多挤两个小时也只是更熟练地看别人做；如果是前者，玩一晚并不会把进度清零。

出处 1 2

在关键处选难的那条路：先自己猜怎么做、哪里会出错，再看 AI 的结果；过一两天关掉 AI 重做一遍或讲给别人听；再换一个条件看还会不会。配环境、调端口这类消耗意志力却不长本事的“假困难”，尽管交给工具。学 AI 真正该花时间的是判断：这件事值不值得做、怎么拆、做出来的东西好不好。这也意味着，高效不等于把每一分钟都塞满输入，而是把有限的时间放在会逼你犯错和复盘的地方。

出处 2 1

如果今晚确实想玩，可以先给自己定一个很小的学习动作，比如用 AI 做一个你真正想要的小东西，先写下你打算怎么做和预判哪里会错，再让 AI 动手，然后对比差异。玩完之后隔一天，关掉 AI 把这个东西重做或讲一遍，卡住的地方就是下次该学的。这个动作能帮你判断：你缺的是时间，还是学习方式本身在空转。若卡住的是判断和拆解，那值得投入；若只是操作不熟，交给工具即可。

出处 2 1

立正把 AI 看作手艺而非知识学科：能解释概念、能跟着教程跑通流程，都不等于能稳定交付结果。课堂式学习最大的风险是制造“我懂了”的错觉，让人迟迟不动手，还把出错当成失败而不是反馈⁠1。他提到，跟着 tutorial 或 toy project 走，建模、拆解、验收、诊断这些最要紧的环节其实都被别人替做了，自己只是走流程，一进真实场景第一步就可能崩⁠1,2。所以“先系统看课”如果变成把课刷完再动手，反而会拖慢真正的学习。

这不意味着课程没用。立正自己的课程安排是先学 AI Coding 的基本功（环境、报错、怎么描述需求），再做核心作业，然后一边学一边完成一个真实项目，其余应用课遇到问题时再回来查⁠3。他也说真正有效的路径是在使用中逐步升级，而不是先完全学会再开始用⁠4。可以这样理解：课程负责给你工具和概念，项目负责让你暴露“哪里其实不会”。

判断自己是否真学会，可以看撤掉 AI、隔一段时间、换一道题之后还能不能做出来；做出来了只说明当下做得好⁠5。具体做法是先自己猜一遍打算怎么做、觉得哪里会出错，再看 AI 的结果，错了才有得学；然后关掉 AI 自己重做一遍，卡住的地方就是还没学会的地方⁠6。配环境、申请 token 这类“假困难”可以交给工具，难要留给值不值得做、怎么拆、做得好不好这些判断⁠6。