接下来还要挑配图、裁公众号封面、拆成小红书卡片；碰上汇报，还得再做一版 PPT。每个平台尺寸不同，风格要统一，文字不能溢出，最后的文件最好还能继续改。换一篇文章，又要从头向 AI 解释一遍。

最近一批 Codex Skill 瞄准的，正是这段反复发生的“发布前收尾”。创作者看到的是一组配图、一套社媒卡片或一个可编辑 PPT；开发者看到的则是被保存下来的规则、模板、脚本、渲染工具和检查流程。

这篇真正想讨论的不是“又多了几个 AI 项目”，而是同一条内容生产线的两面：它替用户省掉了什么，开发者又为稳定交付搭了什么，以及它离真正的一键内容工厂还有多远。

用户要的不是“AI 会不会画”

假设我刚写完一篇长文，对 Codex 说：

按我平时的风格，做三张正文配图、一张公众号封面，再拆成一组小红书卡片。

从用户视角看，这句话并不复杂。我关心的只有几件事：不用每次重讲审美，几个渠道看起来像同一套作品，文字没有被裁掉，最后拿到的是可以发布或继续修改的文件。

但开发者听到的是另一串问题：

这正是普通聊天和 Skill 开始拉开差距的地方。好 prompt 当然也能调用工具，轻量 Skill 也可能只有一份说明；区别不在于名字，而在于有没有把复用、工具顺序、失败条件和交付格式一起保存下来。

开发者搭的不是一个更长的 prompt

从 Codex 的自定义机制 来看，Skill 更接近一个可复用工作流。一个典型目录可能长这样：

1
2
3
4
5

social-card-skill/
├── SKILL.md       # 适用场景、步骤、停止条件和交付物
├── references/    # 平台尺寸、版式规则、质量标准
├── scripts/       # 渲染、转换、校验等确定性操作
└── assets/        # 模板、样例和视觉基线

SKILL.md 是入口：名称和描述帮助 Codex 判断什么时候该用它，正文规定先读什么、做什么、哪里必须停下来确认。细节资料不必全塞进上下文，可以在需要时再读；确定性的转换交给脚本；模板和样例则作为稳定起点。

这也意味着 Skill 本身不会凭空获得新能力。它不能凭一份说明变出 Playwright、图像模型或 PowerPoint 运行时，而是规定如何使用当前环境里已有的工具。环境没有装依赖、没有权限或没有对应模型，生产线照样会停。

所以 Skill 也不是“记住上次对话”。更准确的说法是：它把规则写进文件并版本化，让下一次新任务可以重新读取，而不用用户再手动粘贴整套要求。

第一条生产线：把文章变成发布包

内容创作者最容易感知的，是从文章到配图和社媒卡片这一段。

ian-xiaohei-illustrations 的目标，是把中文文章里的判断、流程、结构和隐喻，转成统一的小黑 IP、16:9 白底手绘正文图。对用户来说，价值不是“偶尔生成一张好看的图”，而是下一篇文章还能沿用相同的留白、线条和批注方式。

开发者视角则完全不同。要稳定复用这种风格，需要先从文章里挑出值得可视化的句子，再约束构图、颜色、文字量和禁止项；生成后还要检查画面是不是在解释观点，而不是只做装饰。所谓“风格一致”，实际是参考素材、规则和人工判断共同作用的结果，不是模型天然记住了审美。

guizang-social-card-skill 把链路又往前推了一步。它面向小红书图文、公众号封面和 Live Photo，公开规则里包括 3 种画板尺寸、28 个版式、10 套主题，以及从单文件 HTML 到 Playwright 截图的流程。

用户看到的是“同一篇文章输出不同平台的发布包”。开发者看到的却是：识别发布意图，读取平台尺寸，选择模板和图片来源，生成 HTML，调用浏览器渲染 PNG，再决定是否运行 9 条 DOM 版式校验。这里还有一个很重要的真实边界：仓库默认先交付 PNG，再询问用户要不要自动校验，并不是每次都会默默跑完检查。

模板在这里没有被 Skill 淘汰。模板负责提供稳定起点，Skill 负责决定什么时候选哪一套、如何填充内容、用什么工具渲染、失败以后怎样返工。对用户来说，这些细节最好都看不见；对开发者来说，它们才是“以后还能再做一次”的原因。

第二条生产线：从只能看的截图到能改的 PPT

PPT 是更能暴露“交付合同”的案例。

用户说“帮我复刻这页”，通常不是想得到一张图片塞进 .pptx，而是希望标题真的能改、卡片真的能挪、图表还能换数据。只有截图、扫描 PDF 或图片版旧 PPT 时，这个需求尤其真实。

image-to-editable-ppt-skill 就围绕这件事展开。它会尽量把可读文字重建为原生文本框，把简单几何重建为形状，复杂视觉则保留成独立图片资产。对用户来说，结果从“只能看”变成“还能接着做”；对开发者来说，“可编辑”必须被拆成能验证的对象清单、页面状态、渲染对照和最终文件检查。

这条生产线远没有标题听起来轻松。项目 README 明确提醒：单页可能超过 10 分钟，10 页任务可能耗尽 5 小时额度，还会消耗 OCR、图片 API、多智能体和大量 token。它也不承诺 100% 还原。把这些成本写出来，比一句“AI 自动转 PPT”更接近用户真正会遇到的体验。

CyberPPT 处理的是另一类需求：高密度、咨询风、可编辑的正式汇报。它把证据底稿、故事线、风格确认、逐页视觉蓝图、可编辑层和多轮质量检查接进流程。仓库自己的建议也很诚实：让 AI 完成约 90%，剩下 10% 由人收尾；复杂曲线和图标容易有偏差，追求 100% 会显著增加 token 与调试成本。

“生成了”不等于“交付了”。真正的终点是能打开、能修改、符合尺寸，并且知道哪些部分仍需要人工复核。

第三类 Skill 其实不太像工厂

并不是带着 SKILL.md 的项目都会形成完整生产线。

Awesome-Journal-Skills 更像期刊与会议写作规则的索引。它的深度包可以覆盖选题、识别策略、表图规范、投稿和审稿回复；另一些广度合集主要提供 venue fit、写作风格和路由信息。

截至 2026 年 7 月 10 日，项目 README 报告了 289 个 pack、4030 个 SKILL.md。这个规模说明 Agent Skill 生态增长很快，却不代表 4030 份内容都经过了学术事实审查。它当前也更偏 Claude Code marketplace 和通用 Agent Skill，并非 Codex 专属项目。

对研究者来说，这类 Skill 可以少翻几遍投稿规范；对开发者来说，它的核心更接近知识路由和上下文选择，而不是浏览器渲染、文件验证与失败恢复。引用是否真实、方法是否适用、数据能否交给外部模型，仍然需要研究者自己负责。

把它和前两个案例放在一起，反而能看清一个光谱：有的 Skill 主要保存审美与规则，有的连接模板、渲染器和校验器，还有的已经带着状态文件与失败恢复。把它们统称为“内容工厂”很方便，但工程成熟度并不一样。

它不是一键魔法

从用户视角看，好的 Skill 应该让操作越来越短；从开发者视角看，稳定性来自更多明确约束，而不是更强烈的承诺。

真正使用时，至少还有这些成本：

• 安装与环境：浏览器、字体、Office 运行时、Python 或 Node 依赖缺一项，都可能卡住流程。
• 时间与费用：图片生成、OCR、多智能体和长文档重建会消耗额度，也可能比手工改一页更慢。
• 随机性：同一套风格规则能提高一致性，不能保证每次构图都合格。
• 人工复核：事实、引用、版权、错字、复杂图表和最终审美不能只靠“脚本通过”。
• 隐私与权限：论文数据、客户材料和未公开方案进入哪些模型、脚本和外部服务，需要在运行前说清楚。

一条生产线真正成熟的标志，不是它永远不失败，而是失败能被看见：知道停在哪一步，保留了哪些中间文件，修正后能否续跑，错误产物会不会被误当成最终交付。

什么最值得做成自己的 Skill

我现在不会再用“公共知识还是私人偏好”来区分价值。代码工作流同样值得 Skill 化：项目入口、迁移命令、测试、回滚和发布验收，和内容工作流里的尺寸、审美、渲染与校验，本质上都是稳定约束。

更实用的判断方法是“三次法”：同一类任务连续做三次，如果每次都在重复解释相同规则、整理相同文件、执行相同步骤，就值得考虑封装。

动手前，我会先回答六个问题：

1. 什么样的请求应该触发它，什么请求不该触发？
2. 用户需要提供哪些输入，缺少什么就必须停下来问？
3. 哪些步骤交给模型判断，哪些更适合确定性脚本？
4. 中间文件和状态写在哪里，失败后怎样继续？
5. 什么算完成，哪些检查能自动做，哪些必须让人确认？
6. 用户最终拿到什么：一张预览图，还是可继续编辑和发布的文件？

这六个问题答不清，Skill 很可能只是一个收藏起来的长 prompt。答清以后，它才开始像工作流。

所以，Codex Skill 被“玩成内容工厂”真正有意思的地方，不是 AI 突然更会写、更会画了。创作者想要的是少说几遍、少做几轮机械整理，最后拿到能用的东西；开发者要做的是让这份“能用”变成可重复、可观察、可验证的交付合同。

两种视角合在一起，内容工厂才不只是一个好听的比喻。

如果重构博客能打卡集章，我现在应该能换一杯免费咖啡～

每次重构的理由都很充分：上次主题不够简洁、部署流程不够优雅、字体看着不顺眼……反正就是不想承认一件事————我花三天调 CSS，却三个月没写文章。

这次重构其实变化挺大的——我换了个新主题，名字叫 licsber，听起来像某种神秘的宗教，但实际上就是我自己造的轮子。

为什么不用现成的主题？现成的主题就像租来的房子，总觉得差那么点意思。自己写的主题虽然简陋，但每一个像素都在喊”这是我家”。

新主题加了不少花里胡哨的东西：

• Hero 区域会动 —— 没错，加上了打字机特效，是不是有这么一点现代化了。

• 侧边栏有了头像 —— GitHub 头像往那一摆，顿时有了”这是一个正经博主”的错觉。下面还写着”软件工程师 / 开源爱好者”，其实开源项目 star 数两只手数得过来。

但最本质的东西没变：还是 Hexo，还是 Markdown，还是那几篇陈年旧文。node_modules 倒是又胖了 200MB，我对着 Dockerfile 自言自语了一个下午。

为什么要重构？

大概因为写博客太难了。你得有想法、有表达欲、还要担心写完之后自己三天后就觉得那是垃圾。但重构博客不一样——它是纯粹的体力劳动，是无需动脑的安全区，是程序员最优雅的拖延方式。

“我不是没写东西，我在优化写作环境呢。”

听起来是不是很高级？

所以欢迎光临我的第五次博客。内容可能还是那些，但加载速度理论上快了 0.3 秒——如果你正好用 2G 网络的话，应该能感受出来。

下次重构再见 👋

如果国家掌握了所有生产资料，我们就称其为完全的社会主义国家：大家人人生而平等，向国家提供相同的“社会必要劳动时间”就可以换取自身、也即私利的必要生活资源。

现代化中国显然还未达成这点，我们仍需要市场经济体制，靠市场来完成资源的一次分配，依赖最公平的教育与考核将人们分为三六九等，这样拥有更多生产力的人也就可以获取到更多的社会资源。

同时，由于生产资料的未全部国有化/集体化，持有生产资料的个体会获取除了资源以外的东西，即对分配的管理权。

听过一个说法：爱情就像溺水之人忽然抓住的一只手，强劲有力，将人从泥潭中解救出来。

可如果一个人在溺水时才想起你，才需要你，那你和抽屉里那盒过期的止疼药，又有什么分别？

人终究无法永远充当另一片浮木。浮木也会吸饱水分，然后沉默地沉入水底。

我们带着残缺和伤口踏入一段关系，期待从对方的世界里获得救赎————但这不是爱，这只是自己无法温暖自己，便借着他人的体温来取暖。当一个人没有给予爱的能力，爱情就变成了应急措施，而非生活本身的质地。它像夜空中偶尔划过的流星，惊艳一时，却无法成为长久照亮彼此的恒星。

建立在需求与依赖之上的情感，注定缺乏相互扶持的根基。一个人若只在困顿无助时转向你，把你当作生命中的备用选项，这份情感的纯粹与深度，便值得怀疑。

陪伴

但人毕竟是社会性动物，渴望陪伴是一种根植于本能的需要，不是精神满足层面上的”想要”，而是像身体对水的渴求一样客观存在。

问题在于，当一个人沦为另一人的浮木，这段关系就悄悄变了质。浮木在照顾溺水者的过程中，更像是在豢养一只宠物。溺爱固然也是爱，但宠物关系注定不对等——它的感激源于自身的匮乏，而非对浮木本质的欣赏与爱慕。

你不能苛求宠物听懂你说的话，也不该反过来要求它关注你的生活起居。说到底，用宠物来填补自己的孤独，这本就不是它该承受的重量。

救赎

那么，什么才是真正的相爱？

我想，应该是两个灵魂的彼此救赎。

说”救赎”或许言重了，显得我们像是活在什么苦情戏里。但日子确实不易，布满了磕磕绊绊的痕迹。而在这不易之中，我们学会成为彼此的光——不是那种刺眼的、用来照耀的强光，而是冬夜里壁炉中微微闪烁的火光，让人知道这里有人，这里温暖。

是在彼此的眼中寻找光亮，是那种”有你，真好”的笃定。是愿意倾听对方心底的声音，哪怕它微弱得像夜空中最遥远的星光；是愿意触碰彼此的伤痕，因为那些裂痕背后，藏着同样坚韧的生命力量。

我不奢求波澜壮阔，只祈祷岁月对我最大的庇护，就是让我在一份波澜不惊的爱里，走完此生此世。

所以，你做好准备了吗，我的爱人？

我们将在未来的某一个午后，相知相识。然后一起度过一个又一个冬夏，无论晴空万里、乌云密布，都能拥有携手同行的坚定。

愿意并肩站立，共享人生风雨与阳光，才是通往真正幸福的道路。

很多“聪明人”的思维都是线性思维，拿到任务，分解成小项，逐个完成，一步一步的像是在做证明题：期待着攒够一个又一个的事实和推理，最后拼图一般将它们串起来，达成某项任务。逻辑层面上看起来无懈可击，仿佛一切困难都可迎刃而解。

不可否认的是这套思维在应试方面屡试不爽，因为有一个天然的假设是存在的：“所有问题都有标准答案，问题在设计上就是逻辑可解的”。但是习惯这套“逻辑“的人，在处理现实世界的问题时，往往会不自觉地将自己带入死胡同。

逻辑 vs 现实

我把上面那种叫”逻辑关联”，与之相对的是”事实关联”。生活中这种思维陷阱到处都是：

• 白菜3块钱一斤，15块钱可以买五斤白菜
• 你们工厂一个月能产3000个零件，那明天先给我10个吧
• 这个项目比较急，上次排期一周，我再给你一倍的人，三天给我做出来

听起来好像没毛病？但仔细想想：

• 生一个孩子需要9个月，生一对双胞胎需要18个月
• 生一个孩子需要9个月，9个妈妈是不是只要1个月？！

有时候其实很难意识到这样的思考模式存在的问题，这也是《人月神话》里屡次提到的困境。

专注解决问题的思维方式久了，就会慢慢开始只在乎逻辑关联，而忽略事实关联，就会开始期待一种“银弹”，说是缘木求鱼也不过如此。

初级项目经理最爱的蠢问题

很多初级项目经理最大的毛病，就是总觉得所有事都该有个进度条。这样他们就能直观地”看到”进展，要做的也不过是按排期表往下催。

这种人最喜欢问：”你这个要多久才能做出来？”

享受管理者的权力，却不承担该有的角色义务。

项目经理真正该问的是：”你还需要什么帮助才能做得更快？”

优秀的项目经理知道，项目进度不是靠”完成了多少”来判断的，而是靠如何拥有充足的资源去大规模试错。项目经理的任务是确保需求被满足、项目成功交付。

但现实里X-Y本末倒置的现象太多了：为了完成目标定了一堆KPI，最后完全忘了最初的目标，只顾着追KPI。就像前阵子北京环卫工买新鲜白菜当厨余垃圾事件一样————政策目标是垃圾分类，上面定了每种垃圾的数量指标，一执行就变了味，最后闹出笑话。

程序员不是推土机

还有一种常见的误区：很多项目经理在向上级汇报进度时，乐于享受“管理者”的光环和成果，却常常忽略了一线执行者的感受。这也是为什么一线员工本能地反感那些只会催进度、不懂业务、不下场执行的管理者。

本质上，软件开发的最大变量是“人”，“人”不是可以随意替换的零件。对“人”的管理，远比流程管控复杂得多。写代码不是搬砖，项目经理面对的，是有情绪、有思考、有惰性、更有创造力的活生生的人。你不能指望给出1+1，总能收到2的结果；同样的任务，同一个人在不同状态下，效率和成果也可能天差地别。积极主动时，1天就能搞定；消极怠工时，再多时间也谈不上交付。

这正是与传统行业的根本区别。造房子，哪怕换了工人，只要按照规范施工，进度和质量差异不会特别大；但在软件开发中，再烂的挖土机也能挖出一个坑，而最厉害的程序员如果状态不佳，也可能写出一堆“屎山”代码。

因此，优秀的项目经理绝不是填进度表、出汇报PPT那么简单。管理“人”是一项更高阶的挑战。

悲剧是怎么炼成的

对工程师来说，遇到问题、解决问题是日常。但如果问题占用了远超预期的时间，那就是对自己能力和自信的打击。

这时候如果项目经理不专业，硬推进度，工程师就会开始”掩盖问题”。

我一直觉得，让负责技术攻坚的人去追进度是件很可惜的事。悲剧的根源其实是管理能力的不足。真想做到结果导向，需要的是：目标的制定和拆解、工作计划的精确评估、真实有效的复盘、信息同步和应对突发状况的能力。

这些都对领导者要求很高。如果能力不足以管理结果，大家就只能去管理过程————那结果便可想而知了。

参考

工程师想要做管理？先改变你的思考方式

从程序员到项目经理：为什么要当项目经理

母校湖边有一处牌子，上面写着“花开堪赏直须赏，莫要折花空赏枝”。

我觉得不好。花期到了，恰是最美的时刻。似，恰同学少年，风华正茂，更需把握时机，趁春光正好，趁风头正劲，发挥好这一刻。

哪怕为了这一刻就此香消玉殒，也要勇敢地去追求，积极地去争取，莫要让时间风化一切，人生从来不是活365天，而是活在每一个耀眼的瞬间。

依我看来，这正是“花开堪折直须折，莫待无花空折枝”。

尝试去慢慢做一些practical的事情，会让你减轻许多焦虑感，掌握一技在手，安全感也就自然而然。

其实我比较羡慕厨师这个行业，一技在手，别人都会夸你“烧得一手好菜”。但是厨子和外界的联系太多了，袁枚有言“凡物各有先天，物性不良，虽易牙烹之，亦无味也”，厨子需要外界提供上好的食材，需要屠夫和菜农，但他们在现代标准化的流程中丧失了其风味，连带影响了上游的创造者，限制了其发挥。

但是计算机是一个从无到有的世界，是构筑在现代数学之上的理想国。普通家庭花3000块买个电脑，带来的创造性不会比九万八的苹果电脑更低，这其中人的主观能动性更为重要，这也是张雪峰所说“计算机是穷人家孩子的首选”之由来，相对而言，投入的本金很少，产出很高，也即性价比很高。

喜欢计算机，作为技术人，编程是充满乐趣的创造性工作（此处的工作不是认真工作中的工作，而是诸事自己掌控，脑力的结晶），看着自己写的代码一个个work起来，心中的喜悦是溢于言表的，要记住这种感觉，时常体会，才能让自己不至于陷于迷茫。

有些同学质疑项目越来越壮大之后，个人的掌控力会渐渐不足，毕竟软件开发工作是复杂的，虽然我们在极力用各种工程实践让一切变得有序可控，但它依然是依赖个人能力的一种创造性活动。这时候就需要一个舵手作为领导者来把控方向，作为领导者，我认为也不能带着白手套，而是积极参与，深入实践。这样才能最大程度的避免外行指导内行，要跟随最新的技术趋势，保持自己的核心竞争力。

愿不忘初心。

我的专业是软件工程，顾名思义，软件和土木之类的相似，也是一个系统性的工程，系统就不免牵扯到人、机、料、法、环的方方面面，其中占据主导因素的就是参与项目的人。

软件工程，研究的便是如何将「软件项目」以标准化「工程项目」的方式去运作，即，尽量剥离掉人的主观能动性，发挥哪里需要哪里搬的“螺丝钉”作用。而不是像现在众多开源兴趣项目那样，以个人开发者的身份掌管一切、运作一切，一旦原作者弃坑，那么项目即宣告死刑，像ReiserFS作者，进监狱之后，Linux内核就把它标记为了Deprecated，无人问津。

但是任何人都不是等同的，作为“螺丝钉”也会有不同的型号，这里先不谈作为个体的独特个性，仅仅是为了能够有效的协作，身处同一个项目的“螺丝钉”们就需要不断地交流来对抗信息差，也即同步信息。

以下常见的协作问题很容易遇到：

1. 大家对项目最终愿景的理解不同（不明白设计初衷/不了解最终客户需求）
2. 同一职能的人们水平不同（项目中老带新非常常见/某些新技术只有少数人理解）
3. 分工角色和责任不明确（同一问题可以从不同方面解决/团队中某小团体更为强势）

对于一些小项目可能无关痛痒，十人以内还属于可以有效对齐的规模，依靠定期的会议沟通，即可同步所有人。但一旦超出规模，还按照原先的方式沟通，项目就可能会脱离控制，因为人与人之间的沟通是全连接型的，这时候人们往往会按职能来拆分小团体解决，比如前端团队、后端团队、运维团队、测试团队，本质上还是各个团队的领头人，即leader，承担了原先的职能作用。

设想一下，这样的项目团队，在正常的开发迭代周期内，现在接到了加快推进项目的任务，领导决定派遣更多人手来支援、分担项目任务，新加入项目的人可以直接上手干吗？

很明显不太可能，新人至少需要知道项目需求，阅读项目开始至今的开发文档、会议记录，再和项目组已有的成员沟通细节，才能尽可能地无缝加入项目进程。

而加入一个人，则意味着团队原先的N人，都新增了N条沟通链路，再加一个人，就又是N+1条链路，人越多只会越乱，最终大家在沟通同步上浪费越来越多的时间，导致项目虽然看上去增加了人手，但效率只会越来越低。

有没有一种解决方法呢？我认为有，因为问题的本质出在全连接沟通上，假如有这么一个人，他和所有人交流，并且把所有人的信息都同步到和他一致，那全连接的n²级别链路就简化为了n级别，这个人就是项目经理，所以项目经理这样一个角色，职责非常重要，他是项目不至于陷入混乱的前提和保证。

项目经理就有点类似BGP组网中的路由反射器RR，常规的IBGP节点之间都需要建立全连接关系，有了路由反射器之后，反射器可以作为中间节点汇聚所有路由信息，然后同步给其他IBGP节点，这样节省了节点之间的巨量连线和处理路由信息的额外负载。

原图链接：https://img1.sdnlab.com/wp-content/uploads/2017/11/EBGP-IBGP-fig-6.png

当然《人月神话》作为软件工程的圣经，肯定不止告诉了我们这些，后续我看看结合现实再写一篇心得体会，好书值得慢慢回味~

这个话题其实开始于大概三年前的一次讨论，当时我身为学校实验室的负责人，在忙活一年一度的招新工作。大致介绍下我们实验室的情况，说是实验室，其实更偏向因兴趣结合，有导师带队的项目工作坊，在机器人竞赛方面有着深厚的经验积累和历年优秀的战绩。大家呢基本都是技术出身，每个人在上位机视觉、下位机控制、硬件和机械结构方面各有所长，因为我是软件方面做得比较多，所以软件类的招新题是我来出。

在我们软件组内部商量的时候，就有人提出考核的方式是更偏现场小题，还是工程项目类似的综合大题，前者可以确保考察到个人能力，但是考察方面并不全面，现场如果加上偏整体的简答题，招新时间就会太长，后者自己购置材料，完成类似循迹小车、倒立摆一样的综合课题，现场以硬性的性能指标验收，更能反应综合实力和对自动化、电控等方面的理解，但是会存在作弊的问题，即作品可能是由哪些学长学姐、自己家人帮助完成的，招新现场时间较短，可能提问反映不出来到底是不是自己靠实力独立完成的。

后面我们依然选择了后者，辅以招进来之后集中培训三个月，再来一场笔试考察大家的学习能力。简要讲讲我当时的看法，我和副组长的分歧集中在，面试者如果借用了外力的帮助，这个外力算不算他实力的一部分。我认为算，因为我们招新的目的就是打比赛、写论文、搞专利、做项目，需要能打的人，在项目中遇到一些困难，不管是技术上的困难，还是经济、流程上的困难，都需要人来克服。他这一次通过自己的关系，解决了问题，达成了目的，那下一次在我们的项目中，他也可以继续使用关系来构成帮助，这对我们是有益的。尽管你可能说，这不是他个人实力的一部分，可能做技术的人瞧不起这样没有真才实学的“混子”，但是为了集体的利益目标，他的存在有一定的合理性，而且人不会一直甘愿当一个混子，肯定他也会努力学习，提升自己的实力和话语权的。

从学校出来步入社会后，我发现工作中也是如此，虽然不想承认，但是“关系户”手里的关系，属于个人资源，确实也是个人实力的一部分。有些事情确实就需要这样的人出马，能减轻工作中很多繁琐，这也是我认为的，能够解决问题就是好的，有一点结果导向论了。奋斗、努力、刻苦钻研，最终解决了一个技术问题固然令人称赞，但是现实世界很多问题都不属于技术问题，纯粹是管理、流程类问题。在这些事情上，你的努力很可能就是事倍功半的，搞不好还会出幺蛾子，所以有时候追寻技术的纯粹性是好，也不能忽视别人在另一条路线上的能力。

常常听到，你十年寒窗，凭什么比得上我三代经商。那么普通人就毫无翻身之力吗？我认为也不是，现代教育制度其实已经给大家尽可能的机会平等了，在普世追求面前，给自己孩子安排一个工作，子承父业之类的桥段其实已经少了很多，至少看起来已经很不容易了。阶层固化依然存在，但如果不付出努力，大家的阶层都在往下掉，想要保住还是需要后天，不会出现皇子一出生就世袭这样的事情了。

以上。

断断续续博客也重构了四次了

博客园：https://www.cnblogs.com/licsber

语雀：https://www.yuque.com/licsber/blog

Recent

自建：https://licsber.site

灾备：https://blog.licsber.site

技术栈

1. 博客本体：Hexo（基于NodeJS）
2. HTTPS: Let’s Encrypt 泛域名证书
3. 灾备：Github Pages
4. CI/CD：手动build Docker镜像
5. 镜像仓库：阿里云ACR服务（个人免费）
6. 静态文件服务：nginx
7. 反向代理服务：Traefik
8. 图床服务：Minio + Cloudflare反代（防刷流量）
9. 服务管理：K8s（杀鸡用激光炮

欢迎友链~

这种信息不对称往往很难意识到，同样也没有银弹，最近几天的深入学习使我深刻地理解了它的意义，在我的知识领域，明白了为什么对于编程的初学者来说，即使是偏向口语化的代码看起来也像天书。

如上图，以程序员懒得去写的猜数游戏为例，规则很简单，代码生成一个随机数，用户不断输入猜测，代码则提示用户输入的数比生成的数大还是小。

但我从没意识到的是，短短十几行代码，就已经包含了编译工具链安装和使用、编译执行流程、程序入口点、变量定义、基本语法、类型系统、标准库、输入输出、顺序结构、大小比较运算符、分支结构、模块导入、随机数库调用生成….这么多东西。

如果已经有了这些前置知识，没有程序员愿意浪费时间来写一个猜数游戏，因为过于简单，但对于新手来说，正是一些前置知识的缺少造成了毁灭性的后果，编程的学习曲线过于陡峭让他们知难而退，像是一层厚障壁，不突破就只能被永远隔绝在外，永远无法体会编程的乐趣。

同样，理解我上面这段话也需要一些前置知识，同样受“知识的诅咒”影响，人类真是太可悲了。如：想要理解“没有银弹”，至少需要读过《人月神话》一样，没有这些共享的知识会让交流变得难以进行，变得鸡同鸭讲。

常识便是教育的最大阻碍，假如无法使用领域内常识性的专业术语，那么我就无法精确描述我擅长领域的某一概念，但一旦使用了这些术语，就会令未掌握这些术语的人感到迷茫，就像是一种诅咒，始终萦绕在上空。

从这个层面上说，人真的很孤独，拥有共同语言是一件很难的事情，像是我们在评价别人时，也常常难以认识到自己的“习以为常”，殊不知别人不一定有我们同等（优渥或寒酸）的条件、出身，“未经他人苦，莫劝他人善”，我们能做的便只有尊重他人命运，做好自己，过好自己的生活，不过度干涉他人就是最好的处世之道了，剩下的就交给际遇吧。

说到孤独，在这里也希望我未来的伴侣，如果我还能遇到那个她的话，能够和我拥有着相似的语言，同等或互补的知识架构体系，要不然人间走这一遭也未免太可怜了。

1. 当时看了B站一期节目 英文名可以没有任何意义 于是决定给自己整一个
2. 因为我姓刘 所以想要以L字母开头
3. 想要自己成为一个完美的辅助 完美的库人才 所以自己名字里加了lib
4. 为了平衡 后面的字母想要不往上也不往下的 对比起来er不错
5. 剩下就是随缘增加字母了
6. 后来因为觉得Licsber看起来不如licsber简短
7. 所以后续表示名字的时候使用小写 表示我的组织/设备时大写