企业官网建设流程全解析

1. 这句老话到底在说什么

"三分技术，七分人品"这句话，我在刚入行那几年听得耳朵都快起茧子了。那时候在一家做企业信息化的公司写后端，带我的老组长是个四十多岁的老工程师，技术极硬，但脾气也极倔。每次项目复盘，他都要把这句话拎出来讲一遍，讲得我们这些刚毕业的年轻人心里直犯嘀咕：我辛辛苦苦学了四年计算机，刷了那么多题，到头来你告诉我技术只占三成？

后来自己带团队、做架构、跟不同背景的人协作，慢慢才品出这句话的味道。它其实不是在做一个精确的百分比分配，而是在描述一个协作型行业里的价值权重。计算机这行，尤其是工程化的软件行业，早就不是一个人关在屋子里写代码就能改变世界的年代了。一个稍微像样的系统，背后都是产品、前端、后端、测试、运维、数据、安全等一堆角色在拉扯。你技术再强，如果沟通时把同事怼得下不来台，评审时只顾炫技不顾业务约束，出了问题第一反应是甩锅，那你的技术价值会被大幅打折。

所以这句话的核心，我认为是在说：技术决定了你的下限，而人品（或者说职业素养、协作能力、责任心）决定了你的上限。技术让你能进这个门、能干活，但能不能把活干好、能不能被人信任、能不能在关键时刻被委以重任，靠的是技术之外的那部分东西。这篇文章我想结合自己这些年的经历，把"技术"和"人品"这两个词在计算机领域里到底指什么、为什么会有这个权重说法、以及我们该怎么看待它，掰开揉碎聊一聊。适合刚入行的新人，也适合工作几年开始带人、开始困惑于"为什么技术不如我的人升得比我快"的朋友。

2. 拆解"技术"与"人品"在计算机领域的具体所指

2.1 这里的"技术"远不止写代码

很多人一听"技术"，脑子里浮现的就是敲键盘的速度、算法题的正确率、对某个框架 API 的熟悉程度。这些当然算技术，但它们只是技术里最表层、最容易被替代的部分。我见过不少面试时算法题秒解的人，进了项目连一个带事务的接口都写不利索，因为他不知道线上环境里数据库连接池会耗尽，不知道并发下库存会超卖，不知道一个没加索引的查询能把整个库拖垮。

真正的技术能力，我倾向于把它拆成几层。最底层是计算机基础，操作系统、网络、数据结构、数据库原理，这些东西决定了你遇到没见过的问题时，能不能从原理层面推理出方向。往上一层是工程能力，包括代码组织、模块划分、异常处理、日志设计、测试覆盖，这些决定了你写的东西能不能被别人维护、能不能在出问题时被快速定位。再往上是系统设计能力，面对一个需求，你能不能在性能、成本、可维护性、交付时间之间做出合理的权衡。最上面一层是技术判断力，知道什么场景该用什么方案，什么技术是过度设计，什么坑现在不填以后会爆炸。

这四层里，越往下越"硬"，越往上越"软"，但越往上越值钱。而"人品"这个词，恰恰和上面这几层都有交集，尤其是工程能力和判断力这两层，几乎离不开一个人的职业态度。

2.2 "人品"在职场语境里的真实含义

一说到人品，很多人第一反应是"做人要善良""不背后说人坏话"。这些当然没错，但在计算机职场里，"人品"这个词承载的东西要具体得多。我把它归纳成几个可观察的行为维度。

第一是靠谱。答应的事情能不能按时交付，交付的东西质量如何，遇到困难会不会提前预警。一个靠谱的人，你给他派活心里是踏实的，不用天天追着问进度。第二是担当。线上出了故障，第一反应是查日志定位问题，还是先想怎么撇清关系。我见过一个同事，半夜被叫起来处理线上事故，他第一句话是"这个模块不是我写的"，第二句话是"但我先看看能不能恢复"。就这第二句话，让他在团队里的口碑直接拉满。第三是协作。代码评审时是就事论事提建议，还是阴阳怪气秀优越；跨团队对接时是主动对齐信息，还是各扫门前雪。第四是诚信。简历不造假，进度不注水，技术方案不夸大，出了问题不隐瞒。

这些行为背后，其实是一个人对"责任"和"他人"的态度。技术可以学，但这些态度一旦成型，改起来非常难。这也是为什么很多团队招人时，宁可要一个技术中等但态度端正的人，也不愿意要一个技术顶尖但浑身是刺的人。

2.3 为什么是"三七"而不是"五五"

有人会问，凭什么人品占七成，技术才三成？这个比例当然不是数学公式，它更像是一种经验性的警示。我理解它想表达的是：在长期协作中，技术差距带来的影响是有限的，而人品差距带来的影响是放大的。

举个例子。两个后端工程师，A 的技术是 90 分，B 是 70 分。单看技术，A 明显更强。但如果 A 每次评审都嘲讽别人代码烂，每次排期都拍胸脯然后延期，每次出问题都甩锅，那团队为了"消化"A 带来的摩擦成本，可能要额外付出大量沟通和返工。而 B 虽然技术一般，但代码写得清楚、注释到位、遇到不懂的主动问、承诺的事情一定做到，团队反而更愿意把重要模块交给他，因为他让人放心。一年下来，B 的成长速度和实际产出很可能超过 A。

这就是"七分人品"的现实逻辑：技术差距可以通过协作、工具、流程来弥补，但人品问题会持续制造新的问题。当然，这个说法有个前提，就是技术不能太差。如果技术差到连基本任务都完不成，那人品再好也白搭，因为你的"靠谱"没有交付物来支撑。所以更准确的说法是：技术是入场券，人品是加速器。

3. 为什么这个说法在计算机领域格外成立

3.1 软件工程的本质是协作工程

计算机领域有个很反直觉的事实：写代码的时间远少于读代码和沟通的时间。有研究说程序员平均只有不到三成的时间在真正写新代码，其余时间都在读别人的代码、开会、写文档、调试、改 bug。这意味着，你的产出很大程度上取决于你和别人的协作效率。

一个系统里，模块之间是有依赖的。你写的接口如果命名混乱、参数含义不清、错误码随意定义，下游的人就要花大量时间猜你的意图。你提交的代码如果没写测试、没写注释、提交信息是"fix bug"，那后面接手的人就要重新理解一遍你的思路。这些行为看起来是"技术问题"，但根源往往是"我懒得为别人考虑"的态度问题。反过来，一个技术一般但处处为接手人着想的人，他写的代码可能不优雅，但一定好懂、好改、好排查，长期看对团队的贡献反而更大。

3.2 技术迭代太快，态度才是长期变量

计算机这行的知识半衰期短得吓人。我入行时流行的框架，现在很多已经没人提了；当年引以为傲的某个技术栈，现在招聘要求里都找不到了。这意味着，你今天掌握的具体技术，五年后可能一文不值。但有些东西是不变的：学习能力、责任心、沟通方式、面对未知问题的态度。

我见过太多"技术很好但停止学习"的人，三五年后就被后浪拍在沙滩上。也见过一些起点不高，但始终保持好奇、愿意啃硬骨头、遇到问题不绕道的人，几年后成了团队的技术骨干。区别不在于智商，而在于面对困难时的选择。而"面对困难不退缩"这件事，本质上就是一种人品——对自己有要求，对结果有担当。

3.3 信任成本在技术决策中被严重低估

在计算机团队里，很多决策不是纯技术决策，而是信任决策。比如，一个核心模块的重构交给谁？一个紧急的线上问题谁来牵头？一个新技术的预研谁来负责？这些决策里，技术能力只是考量之一，甚至不是最重要的那个。更重要的是：这个人靠不靠谱，会不会把事情搞砸，搞砸了会不会及时说。

我做过一段时间技术面试官，后来也参与过晋升评审。我发现一个规律：晋升到更高层级的人，往往不是技术最顶尖的那个，而是技术够用且被广泛信任的那个。因为更高层级意味着更大的不确定性和更多的跨团队协作，这时候"让人放心"比"技术炫酷"重要得多。一个技术很强但大家不敢把重要事情交给他的人，职业天花板其实很低。

4. 我踩过的坑和见过的真实场景

4.1 技术强但协作差，最后被边缘化

早些年我待过一个项目组，里面有个技术很猛的同事，姑且叫他老 K。老 K 对底层原理门儿清，性能优化一把好手，但他有个致命问题：看不起任何人。评审时别人提意见，他一句"你不懂"就怼回去；产品经理改需求，他当面说"你们能不能想清楚再提"；新人问他问题，他头都不抬说"自己查文档"。

刚开始大家还忍着他，毕竟他确实能解决一些别人搞不定的问题。但时间一长，没人愿意跟他合作了。需要跨模块联调时，别人宁愿自己多花时间也不找他；他负责的模块出了问题，别人也不太愿意主动帮忙。后来项目调整，需要选一个技术负责人，大家投票时几乎没人选他。他技术确实强，但在团队里的实际影响力越来越小，最后自己觉得没意思就走了。

这件事给我的触动很大。技术能力是个人资产，但协作能力决定了这个资产能不能变现。你技术再强，如果没人愿意跟你配合，你的产出就会大打折扣。

4.2 技术中等但靠谱，反而走得更远

另一个例子是我带过的一个新人，叫他小 C。小 C 刚来时技术很普通，算法题做得磕磕绊绊，对框架也不熟。但他有几个特点：第一，交代的事情一定有回音，哪怕做不完也会提前说；第二，不懂就问，而且问之前会先自己查一遍，问的问题质量越来越高；第三，代码写得规矩，变量命名清楚，关键逻辑有注释，提交信息写得明明白白。

有一次线上出了个数据不一致的问题，排查了半天发现是他负责的一个定时任务边界条件没处理好。他第一时间在群里同步了情况，然后自己加班把问题修复，还补了一个监控告警防止再次发生。这件事之后，组里对他的信任度明显上升。后来有个新项目启动，需要一个人去对接外部团队，我第一个想到的就是他。原因很简单：把事情交给他，我不用操心。

两年后，小 C 的技术已经追上了大部分同龄人，而且因为对接过多个团队，他的沟通和协调能力比纯写代码的人强出一截。再后来他升了小组长，带了一个小团队。回头看，他起步时的技术劣势早就被抹平了，而他的"靠谱"成了最硬的通货。

4.3 那些"技术至上"论调背后的陷阱

网上经常有一种声音："技术人就应该专注技术，搞那些人情世故是浪费时间。"这话听起来很爽，但我觉得它是个陷阱。专注技术没错，但把"专注技术"当成逃避协作的借口，就是另一回事了。

我见过一些朋友，技术确实不错，但一遇到需要沟通的事情就烦躁，觉得"我是来写代码的，不是来开会的"。结果就是，他们永远只能做被分配的任务，很难主导一个方向。因为任何稍微大一点的事情，都需要协调资源、对齐目标、推动落地，这些都不是纯技术能解决的。

还有一种陷阱是用技术深度来掩盖态度问题。比如，有人代码写得乱，你提意见，他说"能跑就行"；有人不写测试，你说他，他说"测试是浪费时间"；有人不更新文档，你说他，他说"代码就是文档"。这些说辞背后，其实是一种对他人不负责的态度。技术可以讨论，但态度问题没得商量。

5. 怎么理解"三分技术"里的"三"

5.1 技术是硬门槛，不能没有

虽然这篇文章一直在强调人品的重要性，但我必须把话说清楚：技术是入场券，没有技术，人品再好也进不来。计算机行业毕竟是个技术行业，你至少要能独立完成基本的开发任务，能看懂别人的代码，能排查常见的问题。如果连这些做不到，那"人品好"就变成了"人很好但帮不上忙"，这在职场里同样没有价值。

我面试时有个基本判断：技术可以培养，但态度很难改变。所以如果两个候选人技术差距在可培养范围内，我会优先选态度好的。但如果技术差距大到短期内补不上，那我只能忍痛选技术好的那个，因为团队需要有人能干活。所以"三分技术"不是说技术不重要，而是说技术是基础项，不是加分项。基础项不达标，直接出局；基础项达标之后，比拼的就是其他东西了。

5.2 技术达到什么程度算"够用"

那技术要到什么程度才算"够用"呢？我的经验是，能独立负责一个中等复杂度的模块，从设计到上线到维护，全程不掉链子。具体来说，包括能理解需求并转化为技术方案，能写出可维护的代码，能写测试，能排查线上问题，能跟上下游对齐接口。这些做到了，技术就算及格了。

再往上，就是在某个领域有深度，比如你对数据库优化特别有心得，或者你对高并发架构特别熟，或者你对某个业务领域特别懂。这种深度会让你在团队里有不可替代性，但前提还是那句话：你的深度要能转化为团队的价值。如果你深度很强但不愿意分享、不愿意协作，那这个深度对团队的意义就有限。

5.3 技术好但人品差，到底能走多远

这个问题我被问过很多次。我的观察是：技术极强但人品差的人，能走一段，但走不远。在职业生涯早期，技术优势可以掩盖很多问题，因为团队需要你解决问题。但随着层级上升，协作的权重越来越大，人品问题会越来越致命。

我见过技术大牛因为跟所有人关系都搞僵，最后被迫离开的；也见过技术骨干因为甩锅成性，在晋升时被一票否决的。当然，也有极少数人技术强到"离了他项目就转不动"，这种人短期内确实有议价权，但这种状态不可持续，因为团队一定会想办法降低对他的依赖。把技术当成要挟团队的筹码，是最危险的职业策略。

6. 给不同阶段从业者的实操建议

6.1 新人阶段：先把"靠谱"这个标签贴上

如果你刚入行，技术还在积累期，那我建议你优先建立"靠谱"的口碑。具体怎么做？第一，承诺的事情一定做到，做不到提前说。不要为了表现而拍胸脯，也不要因为怕被批评而隐瞒进度。第二，代码写得让人能看懂。变量名别用 a、b、c，关键逻辑写注释，提交信息写清楚改了什么、为什么改。第三，遇到问题先自己查，查不出来再问，问的时候说清楚你试过什么。这三点做到了，你在团队里的信任度会快速上升。

这个阶段最忌讳的是眼高手低。觉得自己技术牛，看不起这个看不起那个，或者觉得写文档、写测试是浪费时间。这些行为会给你贴上"不靠谱"的标签，而这个标签一旦贴上，后面要花几倍的努力才能撕掉。

6.2 中级阶段：技术深度的同时补协作短板

工作三五年后，你大概已经能独立负责模块了，这时候要考虑的是往哪个方向深耕。我的建议是，选一个跟业务结合紧密的方向，比如你所在的行业对性能要求高，那就深耕性能优化；如果对数据一致性要求高，那就深耕分布式事务。技术深度要能解决实际问题，而不是为了炫技。

同时，这个阶段要开始有意识地补协作能力。比如主动承担跨团队对接的任务，主动在评审时给出建设性意见，主动帮新人解决问题。这些事看起来"不产出代码"，但它们会帮你积累影响力和信任度，而这些是晋升到更高层级的关键。

6.3 高级阶段：从"做事"转向"成事"

到了高级工程师或者技术负责人的阶段，你的价值就不再是"自己能做多少事"，而是"能带着多少人成多少事"。这时候，技术判断力和人品的重要性会同时放大。技术判断力让你能选对方向，人品让你能聚拢人心。

这个阶段我最大的体会是：要学会把功劳让出去，把责任扛起来。项目成功了，多提团队成员的贡献；项目出问题了，先反思自己的决策。这样做短期看好像"吃亏"，但长期看，你会赢得真正的追随者。而一个没有人愿意追随的技术负责人，是走不远的。

7. 常见疑问与我的看法

7.1 "我技术好，为什么升职的不是我"

这是我最常被问到的问题。我的回答通常是：升职考察的不是单一维度，而是综合能力。技术好只是其中一个维度，甚至不是权重最高的那个。更高层级需要的是判断力、影响力、协作力，这些都需要技术之外的素养。如果你技术很好但一直升不上去，不妨反思一下：你是不是只关注自己的产出，而忽略了团队的整体效率？你是不是在协作中让人感到不舒服？你是不是只愿意做自己擅长的事，而不愿意碰那些"麻烦"的事？

7.2 "人品好但技术一般，会不会被淘汰"

会，如果技术一直不进步的话。人品好只能保证你不被讨厌，但不能保证你有价值。职场最终还是要看产出的。所以正确的策略是：用人品赢得时间和机会，用技术把机会转化为成果。我见过一些人，因为靠谱被给了机会，但因为技术跟不上，最后还是被边缘化。所以两条腿走路，缺一不可。

7.3 "是不是只要会做人，技术差点也没关系"

绝对不是。"会做人"不等于"技术差"。我见过一些技术很差但特别会来事的人，短期内可能混得不错，但长期看，没有真本事支撑的"人缘"是脆弱的。一旦遇到需要真刀真枪解决问题的场景，就会露馅。而且，真正技术好的人往往一眼就能看穿谁在划水，靠人情维持的关系经不起考验。

7.4 怎么判断一个人是不是"人品好"

我的判断标准很简单：看他怎么对待比他弱的人，看他怎么对待没有利益关系的人，看他出了问题时的第一反应。对上级谄媚、对下级傲慢的人，人品一定有问题；只在有求于你时才热情的人，不值得深交；出了问题先甩锅的人，不能委以重任。这些观察不需要很长时间，几次协作就能看出来。

8. 我个人的一些体会

写了这么多，其实我想说的核心就一句：在计算机这行，技术决定了你能做什么，而人品决定了你能走多远。"三分技术，七分人品"这个说法，与其说是一个精确的比例，不如说是一个提醒：别只顾着埋头学技术，忘了抬头看看身边的人。

我自己这些年最大的成长，不是学会了某个框架或者某个算法，而是学会了怎么跟不同的人协作，怎么在压力下保持靠谱，怎么在利益面前守住底线。这些东西没有教科书，只能在一次次踩坑和反思中慢慢积累。技术可以突击，但人品需要长期修炼。

最后分享一个我一直在用的小方法：每次做完一个项目，除了复盘技术问题，也复盘一下协作问题。比如，这次有没有因为沟通不到位导致返工？有没有因为自己的情绪影响了团队氛围？有没有在关键时刻退缩？把这些记下来，下次改进。技术复盘让你变强，协作复盘让你变稳。两者结合，才能在这个行业里走得踏实、走得长远。