只补充一个点；职场沟通，在技巧层面之上，还有一个目标层面；

如果能在目标层面，先确认彼此的相关利益是一致的，那么再回到技巧层，问题就可迎刃而解——只是要怎么协作才能快速高效地达成这个明确的目标而已；相反，如果在目标层本身就有问题，那就必须要先解决目标问题，才轮得到技巧登场；

先说结论，ai 编程在我个人的体验来说，目前还比较像是一个 “高级加强版的搜索引擎” —— 有帮助开拓的效果，但代码的细节 bug 问题似乎还是很难避免；

具体到最近涉足的几个新领域，使用 ai 能帮助我在一些此前未知的领域迅速地生成一个基础的代码框架；这个过程如果用之前的方式，可能会需要好几天的时间来建立基础体系，确实是大大节约了时间；

但是，这些由 ai 写出来的代码，仅就目前的几个项目样本来观察，都有 bug ，而且，这些 bug 几乎都没法通过跟 ai 继续对话来解决；大部分的情况下，是越改越糟糕，越改离题越远（所以养成了保留各个版本输出的习惯）；所以还是不可避免地要回到人工 debug 而，改掉这些 bug 基本都需要重新再捋一遍细节，看它哪里漏了；结果也就是，前面省下来的时间，后面调试全都还回去了；

这或许是因为我所涉足的领域比较偏门（图像处理，设备控制，3d 重建之类的），不是常见的 crud 这种；有一说一，其他人搞 crud 的命中率还是挺高的；对团队其他人而言，也是“温和的助力”，比如，至少现在团队里无论是谁，在需要的时候，都可以用 ai 来搓一个 web 界面，不一定精美，但至少能用；

总体来看，对我个人而言，有 ai 还是助力，因为如果没有 ai ，我可能都不会去尝试这个领域；

note：

上述结论的得出，应该与模型的水平无关，我几乎尝试了所有模型，从 claude 到 gemini 还有 grok 最新的都用过了，几乎无一例外；
目前没有全面采用 claude code 的“全流程”方案，因为，就目前的反馈而言，其准确度尚不足以支撑更多的“放手”（多轮对话 bug 越改越糟，还没建立往下走的信心）；

也请其他网友补充细节，或提出改进建议；

不建议直接上大车，容易寄；

既然热情上头一时半刻也劝不回来，那就建议考虑先到店里买一个二手 125 本田踏板，先上手练一练，城区好多地方不让进，冬天天气又冷，新手还容易摔车，说不定练着练着就劝退了～～～，到时踏板还可以再卖回给店里，试错成本最小化。（以上建议来自一个换了 5 辆摩托每天在市区开 200 公里帮人修电脑的师傅）

有一个很土的保健功法，名字叫做 “每日晨起搓热双手揉耳 36 下”，有很大概率是精神安慰疗法，但，既然没啥好办法，为啥不试试捏？

美食计

@37Y37 做了很久之前想做的功能。

时间紧任务多，不推荐兼职／远程。

@Sdhjt 丢个简历来看看呗。

@fqrouter2 hoho，目测得很靠谱。

比如，不用api？

爱乐压+1

不推荐 coffeescript 原因自己 google 吧。
一直用 emacs+js2 好用。

这个可以顶。 :D

北京，被解析到 http://surveycentral.tomagochitown.com/home.html 是一个钓鱼网站。

北京联通

@probe301 显然是，但不同的领域需要不同的方式来各显神通地挖坑。挖坑必须是在需求层面的“开发”，作为技术人员，要极力避免技术投入的思维惯性（因为这个是手边最好用的锤子）。

有一本《精益创业》，我在有了教训之后再读，感觉有收获（我估计，在没掉到过坑里之前，就算看到这本书，也会忽视之，不犯错大概是不可能的吧）。

backbone todolist demo as a prototype
http://backbonejs.org/examples/todos/index.html

需求肯定有，问题是：
1，这个需求的刚性有多强（用户基数）？
2，有需求的人如何知道这个产品（推广成本）？
3，是否有获得正向的ROI的潜力（获利方式）？

这几个问题谁也不会有现成的答案，或许真的是要做了之后才能知道。但是，先知道有这么几个问题，建立这么一个概念体系，总是没错的。以我的亲身经历来说，技术人员很容易陷入这样的误区：反正也不难，要不就先做一个试试看？然后放了很多心血进去，辛辛苦苦地做出来了，结果却发现用的人并不多，而且也不知道要怎么去推，销售神马的就更别提了？这种体验，对创造者的热情（这是一种罕见而且宝贵的损耗性资源），是有损害的。

咱们不谈机会成本，就算消耗的仅仅只是业余时间而已，但这其实也是一种巨大的消耗型的投入，花在这里，就没法花在那里。挖一个坑，放了很多心血去填，结果却把自己给埋进去了，这种事天天都在发生。这样的经历或许并无害处，但是人心都是肉长的，次数多了也扛不住的。与其这样，还不如在动手挖坑之前，就引入这种考量。第一次掉到坑里或许是难以避免的，但第二次，多少还是应该尽力去避免一下。

这其实就是需求的确认，对于大家来说，实现需求不是问题，没风险，只需要投时间和精力进去就行了，问题在于，这个需要消耗掉你大量的精力才能实现得出来的需求，它到底是不是一个靠谱的需求，这个对于大家来说，是更重要，但更不被重视的风险。

基于 paper 的描述，从代码实现的层面来推测：

墙在检测到有到某主机的 SSH 行为之后，会有程序来尝试访问这个主机的 80 端口（可能还会访问其他端口），目的是综合采集主机的信息以助判定，即，“主动验证”。各种采集到的信息，被综合用算法来判定其行为模式。如果只有 SSH 而已，没有其他端口，则被算法判定为翻墙主机的系数可能会增高。基于此推测，将目标主机当作标准的服务器来配置，比如，配置 mail 服务等，也会有助于降低被墙风险。

纯推测。欢迎根据 paper 做出的其他推测。