现代软件工程 软件工程师能力自我评价表
这是《构建之法》和软件工程教学的一部分，用于学生/工程师自我评价。
软件工程师如何评价自己的能力？ 有人写Java，有人用C++，还有人用1980年代就出现的 Object-C, 有人写前端，有人写后端，有人偏于行业应用，有人做平台，还有越来越多的人让 AI 进行 vibe coding ... 有人在小公司，有人在大公司，... 如何衡量一些通用的软件工程能力呢？请看下面几部分：
2025 年版 软件工程师能力评价表 (2025 AI-Native 版)
（一）六维工程能力雷达图
第一维：AI模型全栈与权衡能力
专项侧重：研产互促创新、系统优化
内涵：在模型全链路开发中，能准确理解业务需求，在模型效果、推理速度、资源消耗等多重目标间进行系统性的权衡决策。不仅关注技术指标，更关注技术选择如何满足真实场景约束。
关键指标：需求对齐度、技术方案权衡合理性、模型效果与效率的平衡水平、约束条件下的最优解能力。
第二维：AI原生架构与沟通设计
专项侧重：生产级平台、研产互促创新
内涵：将模糊想法转化为清晰架构的能力。通过有效沟通与协作，将业务需求转化为可执行的系统设计方案，并在团队中建立对架构的一致理解。
关键指标：架构清晰度与可理解性、跨角色沟通效率、需求到设计的转化质量、文档与图示的表达能力。
第三维：云原生与约束工程化
专项侧重：生产级平台、系统优化
内涵：在明确的成本、时间、合规等约束条件下，设计并实施工程化方案的能力。理解每个技术决策背后的资源代价，并在约束范围内实现最优解。
关键指标：约束条件识别准确性、资源利用效率、成本控制有效性、在限制条件下的工程创新能力。
第四维：开源协作与需求转化
专项侧重：开源共建、研产互促创新
内涵：不仅贡献代码，更能理解开源社区的真实需求，将模糊的社区诉求转化为具体的功能实现。通过开源协作提升沟通与协作能力。
关键指标：社区需求理解深度、贡献的实际用户价值、协作沟通质量、从问题到解决方案的转化效率。
第五维：智能开发与人机协同
专项侧重：所有专项
内涵：将AI作为沟通与思维延伸的工具，能清晰地向AI表达模糊想法，并将AI输出转化为清晰方案。在人-AI-人的协作链条中发挥核心作用。
关键指标：需求向AI传达的清晰度、AI输出的加工与转化能力、在人机协同中的主导作用、协作流程的优化能力。
第六维：工程领导与系统权衡
专项侧重：系统优化、生产级平台、研产互促创新
内涵：在复杂工程挑战中，领导团队进行系统性权衡的能力。能识别多维度的约束条件（技术、资源、人力、时间），引导团队做出最优集体决策，并将决策清晰传达给所有相关方。
关键指标：多约束条件下的决策质量、团队共识建立能力、复杂问题的拆解与分配效率、领导下的整体工程产出质量。
（二）适用对象： 涵盖后端、前端、移动端、全栈及 AI 应用工程师 评分说明： 请针对以下问题，根据实际情况打分（1-5分）。
-
1 - 理论认知 (Novice): 听说过概念，依赖他人指导或 AI 盲目生成。
-
2 - 独立实践 (Competent): 能独立完成任务，是可靠的执行者。（参与的产品能发布）
-
3 - 团队指导 (Mentor): (及格线/资深标准) 能指导他人，能优化实践，有开源贡献。 （技术博客）
-
4 - 跨域影响 (Architect): 制定标准，设计跨组架构，深度参与开源生态。（开源贡献）
-
5 - 行业引领 (Visionary): 行业专家，开源项目维护者，定义技术方向。（系列科普，教程，讲座，产品和开源项目）
（三）具体评价考察点列表
第一维：AI模型全栈与权衡能力
核心价值：在复杂业务需求与严苛技术约束之间，做出基于数据的理性权衡与最优决策。
考察点1：需求导向的算法设计与分析
-
评估内容：基于具体的业务场景（如推荐系统、实时风控）和明确的性能要求（如响应时间<100ms、准确率>98%），能够选择最匹配的算法与数据结构，并量化分析其时间/空间复杂度及实现成本。
-
能力体现：将业务目标转化为可衡量的技术指标，并在多个可行方案中进行有理有据的选择。
1-5级能力画像（精简示例版）
1分：理论认知者
-
仅了解算法基本概念，无法结合实际场景应用。例如：听说KNN能做分类，就在所有分类问题上都用KNN。需求理解停留在表面，无法转化为具体技术指标。例如：用户说“要快”，就直接选用时间复杂度最低的算法。方案选择依赖他人推荐或简单模仿。例如：看到别人项目用Redis缓存，自己的项目也照搬，不考虑数据特性。缺乏复杂度分析和成本评估意识。例如：为处理十万级数据选择O(n²)算法，导致系统卡顿。
2分：基础实践者
-
能将常见业务场景与标准算法模式对应。例如：知道用户去重用HashSet，排序用快排。开始关注性能要求，但理解较为模糊。例如：知道要“减少内存占用”，但不知道具体目标值是多少。能分析简单算法的复杂度差异。例如：知道ArrayList查询快但插入慢，LinkedList相反。方案选择主要基于教科书规则。例如：数据量小用冒泡排序，数据量大用归并排序。
3分：场景适配者
-
能明确识别业务场景的核心约束条件。例如：移动端应用优先考虑内存占用，服务器端考虑吞吐量。能将非功能需求转化为可衡量的技术指标。例如：“用户体验好”转化为“页面响应时间<200ms”。能对比多种算法方案的复杂度与适用性。例如：对比红黑树和跳表在并发场景下的性能差异。具备初步的成本效益权衡意识。例如：为节省开发时间，接受算法在极端情况下的性能损失。
4分：系统分析师
-
能处理多维度、可能冲突的需求权衡。例如：在高准确率、低延迟、低成本之间找到平衡点。能量化分析算法选择的计算、内存、维护成本。例如：计算布隆过滤器误判率与内存节省的量化关系。能为不同优先级场景设计差异化的解决方案。例如：核心交易用强一致性算法，日志处理用最终一致性。能通过实验数据支持技术决策。例如：通过A/B测试验证新排序算法对用户点击率的影响。
5分：架构决策者
-
能预判业务演进对算法设计的长期影响。例如：为未来数据量增长10倍提前设计分片策略。能建立业务KPI与技术指标的量化关联。例如：建立推荐算法准确率与用户留存率的数学模型。能设计分层降级的系统化算法策略。例如：正常流量用深度学习模型，高峰时降级到规则引擎。能制定算法选型的标准化决策框架。例如：制定团队统一的算法评估维度和选择流程。
考察点2：模型调优与效能平衡实践
-
评估内容：针对特定任务（如文本生成、多模态理解）和资源预算，通过调整LLM参数（如Temperature、Context Window）或应用模型压缩技术，在模型效果与推理成本之间取得可验证的最优平衡点。
-
能力体现：深入理解模型原理，通过实验驱动的方法解决“效果-效率-成本”这一经典权衡问题。
1-5级能力画像
1分：参数试用者
-
仅了解基本参数功能但应用盲目，例如：听说Temperature影响创造性，就随意设置为0.7而不测试不同场景效果。对资源成本无概念仅追求效果，例如：为了微小的准确率提升而使用参数量10倍的模型，不考虑推理成本。缺乏系统化的评估方法，例如：凭主观感觉判断生成质量，无量化评估指标。
2分：基础调优者
-
能针对简单任务调整核心参数，例如：为摘要任务降低Temperature以获得更确定性的输出。开始关注推理效率但优化手段单一，例如：为降低延迟只采用增大批处理尺寸这一种方法。使用基础的评估指标进行对比，例如：比较不同参数设置下的BLEU分数差异。
3分：系统优化者
-
能根据任务类型系统化配置参数组合，例如：为创意写作设置分层Temperature策略，开头高创造性，结尾高确定性。掌握多种效率优化技术并能初步权衡，例如：在8bit量化和模型剪枝之间选择，平衡精度损失与加速比。建立多维度评估体系指导优化方向，例如：同时监控延迟、准确率、token消耗三个指标，寻找帕累托最优。
4分：成本架构师
-
能针对预算约束设计完整的优化方案，例如：给定单请求成本上限，设计混合精度推理+缓存策略的方案。深入理解底层原理并创新应用，例如：通过分析注意力头重要性进行结构化剪枝，达到优于标准方法的效果。构建自动化调优流程持续改进，例如：建立参数自动搜索流水线，根据线上反馈动态调整模型配置。
5分：效能战略家
-
能预见技术演进并制定长期优化路线图，例如：规划从FP16量化到稀疏化再到定制硬件的三年优化路径。创造新的权衡框架解决复杂约束问题，例如：提出“质量-成本-延迟”三维权衡模型，为不同业务线制定差异化策略。驱动团队建立效能优先的工程文化，例如：制定全团队的模型效能评估标准，将推理成本纳入核心KPI体系。
考察点3：端到端性能优化与量化验证
-
评估内容：为实现具体的性能目标（如推理吞吐量提升50%、训练内存占用降低40%），能够设计并实施涵盖数据处理、模型优化到部署推理的全链路优化方案，并提供可复现的性能基准测试报告。
-
能力体现：系统性工程思维，追求从数据到服务的全流程卓越，并用数据证明优化价值。
1-5级能力画像
1分：局部修补者
-
仅针对明显瓶颈做简单修改，例如：发现内存溢出时，简单增大批量大小而非优化内存使用。缺乏系统性视角和量化验证，例如：优化后凭感觉认为“快了点”，无基准测试数据支撑。忽略优化对其他环节的影响，例如：优化模型推理速度却导致预处理流水线成为新瓶颈。
2分：环节优化者
-
能在单一环节实施标准优化手段，例如：在数据预处理阶段应用并行化加速数据加载。能进行基础性能测试与对比，例如：使用时间戳记录优化前后的推理延迟变化。开始关注优化方案的副作用，例如：检查模型量化后准确率是否在可接受范围内下降。
3分：链路协调者
-
能识别并解决跨环节的性能瓶颈，例如：发现数据序列化格式影响端到端延迟，优化序列化方案。设计并执行系统性基准测试，例如：构建覆盖数据处理、模型推理、结果后处理的全链路压测方案。量化分析优化措施的成本效益，例如：计算GPU显存节省与推理速度提升的量化比例关系。
4分：架构优化师
-
能重新设计架构实现性能突破，例如：将串行处理流水线重构为异步流水线，消除等待时间。建立可复现、可比较的基准测试体系，例如：创建标准化的性能测试套件，支持不同优化方案的公平比较。预判并规避优化引入的新风险，例如：在实施模型蒸馏前，评估其对模型鲁棒性的潜在影响。
5分：性能科学家
-
能创新性能优化理论并指导实践，例如：提出基于工作负载特征的动态批处理调度算法。建立性能优化与业务价值的量化关联，例如：证明推理延迟降低10%能提升用户留存率0.5%。构建持续性能优化的组织能力，例如：设计性能看板、建立优化文化、制定团队性能基线标准。
第二维：AI原生架构与沟通设计
核心价值：将模糊、抽象的业务愿景，转化为清晰、健壮且团队共识的技术架构。
考察点4：模块化架构设计与隐性知识的处理
-
评估内容：针对产品需求（如一个AI工作流平台），设计出高内聚、低耦合的模块化架构，撰写包含架构图、接口定义、数据模型和核心决策说明的详尽设计文档，并成功通过跨职能团队（产品、研发、测试）的技术评审。
-
能力体现：将复杂问题结构化，并通过书面与口头沟通建立统一的技术认知，特别是隐性知识的挖掘和分享。
1-5级能力画像
1分：功能收集者
-
设计简单罗列功能模块，例如：将需求文档的功能列表直接转化为代码目录结构。文档仅包含基础信息，例如：架构图缺失模块间依赖关系，接口说明只有函数名。忽略跨团队理解障碍，例如：使用大量技术术语与产品经理讨论架构，无法建立共识。
2分：结构设计者
-
能按功能划分基础模块边界，例如：将系统分为用户管理、订单处理、支付服务三个模块。提供基本的设计文档，例如：包含模块关系图和简单接口定义的Markdown文档。开始关注团队协作需求，例如：为测试团队提供基本的API调用示例。
3分：接口契约制定者
-
设计清晰的模块接口和契约，例如：明确定义服务间通信协议、错误处理机制和数据格式。撰写详尽的架构决策记录，例如：记录选择微服务而非单体架构的具体考量和权衡过程。主动挖掘并显化隐性知识，例如：将“系统在高峰期的特殊降级策略”写入架构文档而非仅口头传承。
4分：认知对齐专家
-
设计支持多视角理解的架构表述，例如：为技术团队提供详细类图，为产品团队提供业务流程架构图。建立架构决策的知识传承机制，例如：创建架构决策日志，记录每次重大变更的背景、选项和理由。推动跨职能团队的技术共识，例如：组织架构评审会，确保产品、研发、测试对系统边界有统一认知。
5分：系统思维布道者
-
设计自解释、自演进的架构体系，例如：创建架构文档的活文档机制，代码变更自动更新相关文档。建立组织级隐性知识管理体系，例如：设计架构知识图谱，连接设计决策、实现代码和运行数据。培养团队的架构思维和沟通文化，例如：制定架构设计工作坊流程，提升团队整体架构表达能力。
考察点5：复杂智能体协作流程设计
-
评估内容：能够将一个涉及多步骤决策与外部工具调用的复杂业务场景（如自动化客服、智能内容创作），分解并设计为由多个智能体（Agent）协同完成的工作流程，明确定义各智能体的职责、通信协议与故障处理机制。
-
能力体现：将业务流程翻译为可执行的、具备容错性的AI系统架构，在这过程中充分利用 AI 工具的效率又确保了长期质量。
1-5级能力画像
1分：简单功能调用者
-
将AI作为单一工具直接使用，例如：用ChatGPT API直接生成客服回答，无多步判断逻辑。忽略异常和边界情况处理，例如：当AI返回无关内容时，系统直接展示给用户。缺乏对长期质量的监控机制，例如：无AI输出质量评估和持续优化流程。
2分：流程串接者
-
能设计简单的多步骤线性流程，例如：先查询知识库，再调用AI总结，最后格式化为回答。提供基本的错误处理，例如：当某个步骤失败时记录日志并返回默认结果。开始关注AI工具的互补性，例如：在创意生成中结合文生图和文本生成模型。
3分：协作架构师
-
设计多智能体协作的通信机制，例如：为审核、生成、优化三个智能体定义JSON通信协议。建立流程的容错与降级策略，例如：当生成智能体超时，自动切换至规则引擎兜底。设计质量监控与反馈闭环，例如：设置输出质量评分器，低质量结果触发人工审核流程。
4分：自适应流程专家
-
设计动态路由的智能体协作网络，例如：基于问题类型自动选择不同的专家智能体组合。实现智能体间的协同学习机制，例如：优化智能体根据生成智能体的历史表现调整prompt。建立端到端流程效能评估体系，例如：监控整个流程的延迟、成本、用户满意度指标。
5分：自治系统设计师
-
设计能自我进化的智能体生态系统，例如：智能体能基于交互数据自动优化协作模式。创造新的AI协同架构模式，例如：提出“反思-行动-验证”的三层智能体协作框架。建立系统级AI治理与伦理框架，例如：为多智能体系统制定责任追溯与安全控制机制。
考察点6：RAG系统架构设计与方案陈述
-
评估内容：基于对业务知识库规模、查询模式与响应速度要求的深入理解，设计可行的RAG系统架构（包括文档切分、向量化、检索与重排策略），并能清晰地向不同技术背景的听众阐述其设计原理、优势与潜在挑战。
-
能力体现：连接前沿技术与实际应用场景，并具备强大的技术布道能力，并能发展 RAG 到新的架构，实现系统 “自学习，自分析，能力自增长” 的结果。
1-5级能力画像
1分：基础组件使用者
-
能调用现成RAG库完成简单查询，例如：使用LangChain的RetrievalQAChain搭建问答原型，但不了解内部机制。陈述停留在功能演示层面，例如：向团队展示系统能回答问题，但无法解释检索质量的影响因素。缺乏对业务场景的适配思考，例如：为法律文档和客服知识库使用相同的分块策略。
2分：流程定制者
-
能根据数据特点调整预处理流程，例如：针对PDF技术文档调整分块大小和重叠窗口。能向技术人员解释核心概念，例如：向研发团队说明向量检索和关键词检索的区别与优劣。开始关注系统性能指标，例如：测试不同向量模型对检索准确率和响应时间的影响。
3分：架构适配专家
-
设计匹配业务需求的完整RAG架构，例如：为百万级文档设计分层检索，结合粗排和精排策略。清晰阐述技术选型背后的权衡，例如：向产品经理解释选择特定向量数据库的四大考量因素。建立持续优化机制，例如：设计用户反馈收集闭环，用于优化检索相关度。
4分：创新架构设计师
-
突破传统RAG架构设计自适应系统，例如：设计根据查询复杂度动态调整检索策略的智能路由层。创造生动的技术布道材料跨越认知鸿沟，例如：用图书馆管理员的比喻向非技术高管解释RAG原理。设计RAG系统的自学习进化机制，例如：实现系统能自动识别新热点问题并优化相关文档检索。
5分：认知系统科学家
-
开创RAG架构的演进新范式，例如：提出“推理-检索共进化”架构，使系统在解决新问题时同步增强知识库。建立组织级的知识增强战略，例如：制定企业知识从文档到智能体的全生命周期管理框架。引领RAG技术的前沿创新与生态建设，例如：主导开源项目实现RAG系统的自我诊断与能力扩展。
第三维：云原生与约束工程化
核心价值：在明确的资源、时间与合规性约束下，构建可观测、可维护、高可用的生产级系统。
考察点7：资源约束下的容器化部署方案
-
评估内容：在给定的有限计算资源（如特定规格的云服务器或本地集群）条件下，设计并实现基于Docker与Kubernetes的容器化部署与编排方案，确保服务满足预设的可用性与伸缩性目标。
-
能力体现：在“巧妇难为无米之炊”的现实约束下，最大化资源利用效率。
1-5级能力画像
1分：环境复制者
-
能在本地运行别人写好的容器配置，例如：用docker-compose一键启动开发环境，但不知道如何修改资源配置。忽视资源限制和成本控制，例如：在测试环境使用与生产环境相同的资源配置，浪费计算资源。缺乏对容器化原理的理解，例如：不知道容器资源限制如何影响应用性能。
2分：容器化执行者
-
能为简单应用编写Dockerfile，例如：将Python脚本打包为容器镜像，设置基础资源和环境变量。了解基本的资源限制配置，例如：为容器设置CPU和内存限制，防止单应用耗尽资源。能部署应用到K8s集群，例如：编写基本的Deployment和Service配置部署Web服务。
3分：资源优化师
-
设计匹配硬件规格的部署方案，例如：为4核8G的服务器设计多容器混部方案，避免资源闲置。实施智能的资源请求与限制策略，例如：根据应用特性设置不同CPU请求量，优化集群调度效率。实现基础的自动伸缩机制，例如：配置HPA基于CPU使用率自动扩缩应用实例。
4分：约束架构师
-
设计多层级资源调度策略应对资源不足，例如：在集群资源紧张时自动降级非核心服务的资源配额。建立精细化资源监控与成本分析体系，例如：追踪每个命名空间的资源使用效率，识别优化机会。实现跨应用的资源协同优化，例如：设计批处理任务与在线服务的错峰调度，最大化硬件利用率。
5分：资源战略家
-
开创资源受限环境下的新型部署范式，例如：设计“边缘-云端”混合调度系统，动态迁移负载平衡成本与性能。建立全栈资源效率驱动的工程文化，例如：制定从代码编写到部署的端到端资源效率考核标准。预测技术演进并制定资源战略路线图，例如：规划从虚拟化到容器化再到无服务器的五年演进路径。
考察点8：自动化CI/CD流水线建设
-
评估内容：为项目建立从代码提交、自动构建、集成测试（包括利用AI生成测试用例以提升覆盖率）、安全扫描到自动部署的完整CI/CD流水线，显著缩短交付周期并保障发布质量。
-
能力体现：通过工程化手段将开发运维流程标准化、自动化，提升整体研发效能。
1-5级能力画像
1分：手动搬运工
-
所有部署步骤全靠手工操作，例如：每次上线都要手动登录服务器，复制文件，重启服务，手忙脚乱到深夜。将测试视为可选项而非必需环节，例如：“这改动很小，直接推到生产吧，有问题再回退”。配置信息散落在各处难以管理，例如：数据库连接串写在某个开发者的记事本里，他请假就没人能部署。
2分：脚本组装者
-
将部分手动步骤写成脚本但各步骤孤立，例如：有独立的构建脚本和部署脚本，但中间还要人工检查测试结果。引入基础自动化但缺乏质量关卡，例如：代码提交自动构建镜像，但测试失败也能手动继续部署。对CI/CD的理解停留在工具层面，例如：“我们公司买了Jenkins，所以有了CI/CD”，但流程依旧混乱。
3分：流水线工程师
-
设计端到端的自动化交付流程，例如：代码提交自动触发测试->构建->安全扫描->预发部署的全流程。建立关键质量关卡确保交付质量，例如：代码覆盖率不达标或安全扫描有高危漏洞则自动阻断部署。善用工具提升流程效能，例如：用AI自动生成边界条件测试用例，将测试覆盖率从60%提升到85%。
4分：效能优化师
-
构建智能化的分层测试与部署策略，例如：小改动走快速通道15分钟上线，大功能走完整流程确保稳定。实现发布过程的渐进式与可观测，例如：先部署5%流量观察指标，没问题再灰度扩大到全量。建立数据驱动的流程改进机制，例如：分析构建失败原因分类，针对性优化减少30%的构建失败率。
5分：研发效能架构师
-
开创组织级研发效能平台与标准，例如：设计跨团队的统一CI/CD框架，将平均交付周期从2周缩短到2天。将AI深度融入研发全流程实现质变，例如：AI不仅生成测试用例，还能自动分析代码变更风险并调整测试策略。构建自适应的智能发布系统，例如：系统能根据市场活动节奏、系统负载情况自动规划最佳发布时间窗口。
考察点9：系统可观测性与成本优化闭环
-
评估内容：构建涵盖日志、指标、链路追踪的可观测性体系，设定关键业务与技术指标（如API成功率、P95延迟），并基于监控数据实施自动化的成本优化策略（如定时伸缩、冷热数据分层），实现性能与成本的双重管控。
-
能力体现：数据驱动的运维与优化能力，建立“监控-分析-行动”的持续改进闭环。
1-5级能力画像
1分：救火队员
-
靠用户投诉才发现系统问题，例如：客户打电话说支付失败，才急忙查日志找原因，业务已受影响一小时。资源使用无度、成本失控，例如：所有服务都按峰值配置，每月云账单比竞争对手高50%却不知道为什么。监控等于“服务器还活着就行”，例如：只监控CPU内存，不知道业务的黄金指标，常出现“服务器正常但用户无法下单”的尴尬。
2分：基础监控者
-
建立基本的服务健康监控，例如：监控所有服务的HTTP状态码，发现500错误就发邮件报警。开始关注资源利用率，例如：发现CPU长期利用率只有20%，手动调整了实例规格。有日志但难以有效分析，例如：日志都输出到文本文件，出问题要花半天时间grep和awk。
3分：指标驱动者
-
建立关键业务与技术指标监控，例如：监控API成功率、订单转化率、P95延迟，数据驱动业务决策。实现基础的成本优化自动化，例如：为流量有规律的业务设置定时扩缩容，夜间自动缩容节省成本。能快速定位复杂问题根因，例如：通过链路追踪发现某个第三方API超时导致整个调用链雪崩。
4分：洞察优化师
-
构建预测性监控与智能预警，例如：系统能提前预测容量不足，在用户感受到变慢前自动扩容。设计精细化的成本-性能优化策略，例如：为不同重要性的数据设计分层存储策略，降本40%不影响体验。建立指标驱动的优化闭环，例如：发现搜索接口延迟增加，溯源到索引策略问题，优化后延迟降低35%。
5分：成本性能战略家
-
开创系统自适应的成本性能平衡模型，例如：系统能实时计算不同优化策略的ROI，自动选择最优方案。建立业务价值驱动的可观测体系，例如：将技术指标直接映射到业务KPI（如延迟影响用户留存），量化技术投入的商业价值。引领组织建立数据驱动的技术治理文化，例如：建立全公司的“性能-成本”看板，技术决策必须有数据支撑，推动从“救火”到“防火”的文化变革。
第四维：开源协作与需求转化
核心价值：深度参与技术共同体，将社区智慧与个人洞察转化为有影响力的实用成果。
考察点10：具备社区影响力的开源贡献
-
评估内容：向主流开源项目（如PyTorch、LangChain、Hugging Face Transformers）提交高质量的代码修复或功能增强（Pull Request），并被上游项目合并；或独立发布在特定领域具有实用价值的开源工具/模型，并获得来自社区的积极反馈与采用（如Star数、Issue讨论）。
-
能力体现：不仅是代码的使用者，更是生态的建设者和贡献者。
1-5级能力画像
1分：社区新成员
-
开始尝试使用开源工具解决问题，例如：学习使用Hugging Face模型库完成自己的实验项目。初步了解开源社区的基本运作方式，例如：阅读项目的README文档，学习如何安装和使用。体验开源带来的效率提升和价值，例如：通过使用开源框架快速搭建起了第一个AI应用原型。
2分：活跃参与者
-
积极反馈使用中发现的问题，例如：在使用LangChain时发现文档缺失，主动补充并提交文档改进建议。分享自己的使用经验和最佳实践，例如：在小团队内部分享如何正确配置开源工具的心得。开始为开源生态做出初步贡献，例如：为中文开源文档项目贡献了技术术语翻译。
3分：代码贡献者
-
具备独立解决技术问题的能力，例如：修复了TensorFlow中一个影响自己项目的兼容性问题。持续为项目贡献有价值的改进，例如：为Scikit-learn优化了某个算法的内存使用效率。获得社区的认可和信任，例如：提交的多个PR被接受，开始参与项目的技术讨论。
4分：项目协作者
-
在重要项目中承担维护责任，例如：成为PyTorch生态某个关键插件的共同维护者。贡献具有广泛影响力的功能，例如：开发的特性被核心项目采纳，成为标准功能的一部分。主动培养新的贡献者，例如：组织线上工作坊，指导初学者如何为开源项目做贡献。
5分：生态引领者
-
创建有持久影响力的开源项目，例如：发起的新框架解决行业痛点，成为领域标准工具。推动开源技术和文化的普及，例如：建立开源基金会，支持更多开发者参与开源建设。实现开源与商业的良性循环，例如：构建可持续的开源商业模式，让高质量开源项目获得持续发展资源。
考察点11：前沿研究成果的工程化转化
-
评估内容：选择一篇具有应用潜力的顶级会议论文，将其核心算法或思想，工程化为一个易于使用、文档完备、可独立部署的工具库或服务，使更广泛的开发者或研究者能够从中受益。
-
能力体现：弥合学术前沿与工业实践之间的鸿沟，创造桥梁性价值。
1-5级能力画像
1分：前沿技术学习者
-
积极关注学术界的最新研究动态，例如：定期浏览arXiv上的新论文，了解最新的AI研究进展。学习将论文中的算法原理应用于简单场景，例如：按照论文描述实现一个基础算法原型验证其可行性。初步建立从理论到实践的基本认知，例如：理解论文中的数学公式与实际代码实现之间的关系。
2分：算法实现者
-
能复现论文中的核心算法并进行验证，例如：成功复现CVPR论文中的图像分割算法，达到论文报告的相近指标。为算法实现编写基础的文档和示例，例如：为复现的代码编写README说明使用方法和依赖环境。能识别和解决复现过程中的技术问题，例如：调整论文中的超参数以适应自己的实验环境。
3分：工程化转化者
-
将论文算法转化为易用的工具库，例如：将ICML的优化算法封装为Python包，提供完整的API文档。优化算法性能以满足实际应用需求，例如：将算法从研究原型优化为支持GPU加速的生产级实现。建立持续改进和维护的机制，例如：为转化后的工具库建立issue跟踪和版本发布流程。
4分：桥梁构建师
-
设计符合工业标准的高质量工程实现，例如：将NeurIPS论文的模型蒸馏技术集成到主流框架的插件生态中。创建完整的使用案例和最佳实践指南，例如：为转化的工具提供多种场景的notebook示例和调优建议。促成学术与工业界的良性互动，例如：邀请论文作者参与工具改进，并将工业界反馈回馈给研究社区。
5分：创新催化者
-
开创跨领域研究转化的新模式，例如：建立自动化的论文到代码转化框架，加速前沿研究落地进程。培养研究转化的专业人才和生态，例如：组织论文复现和工程化的工作坊，形成开源社区。驱动学术研究与产业需求的双向发展，例如：基于工业实践提出新的研究方向，引导学术界的探索重点。
考察点12：对主流开发语言的实战掌握
-
评估内容：对至少一门主流开发语言（C++/Java/Python）有深刻的实战掌握，能够不依赖复杂框架和外部库，快速解决实际问题，并深入理解该语言的核心机制、典型陷阱与最佳实践。
-
能力体现：拥有扎实的编程根基，能够在脱离高级抽象和AI辅助的情况下，直接、高效地创造价值。
-
1-5分级画像：
-
1分（语法使用者）：仅掌握基础语法，编写简单脚本，对内存管理、并发等核心概念模糊，遇到非常规问题依赖搜索和复制。
-
2分（项目参与者）：能在项目中完成分配的功能模块，了解语言的基本特性（如Python的装饰器、Java的集合框架），但对底层原理（如Python的GIL、Java的JVM调优）和复杂陷阱（如C++的悬挂指针、异常安全）缺乏深刻理解。
-
3分（可靠构建者）：能独立负责一个中小型模块或服务。深入理解语言的核心机制（如Python的迭代器协议、Java的类加载机制、C++的RAII），并能主动避免常见的性能陷阱和bug。可以脱离IDE进行有效开发和调试。
-
4分（语言专家）：对语言有专家级理解，能够进行高级优化（如Python的C扩展、JVM的GC调优、C++的模板元编程），并能为团队制定该语言的编码规范与最佳实践。能快速定位和解决由语言特性导致的深层次、诡异的问题。
-
5分（布道师与贡献者）：不仅是语言的使用专家，还可能为语言的编译器/解释器（如CPython、OpenJDK、GCC/Clang）提交过补丁，或在该语言生态中创作了有影响力的库、框架。能预见语言特性的演变趋势，并指导团队进行技术选型与升级。
-
第五维：智能开发与人机协同
核心价值：将AI深度融入开发工作流，成为提升个体与团队效能的“力量倍增器”。
考察点13：高效的人机结对编程实践
-
评估内容：在日常编码任务中，熟练运用AI编程助手，通过精心组织的对话上下文（如提供相关代码片段、错误信息、设计意图），显著提升代码编写、重构和调试的效率与质量，而不仅仅是机械地接受AI的原始输出。
-
能力体现：将AI作为高级智力伙伴，主导并优化协作过程。
1-5级能力画像
1分：AI辅助编程探索者
-
开始尝试使用AI工具辅助日常开发，例如：使用Copilot的代码补全功能加速常见模式的编写。学习与AI进行基础的编程对话，例如：尝试用自然语言描述想要实现的功能，观察AI的生成结果。体验人机协作带来的初步效率提升，例如：通过AI帮助快速生成简单的数据处理函数。
2分：AI协作编码者
-
掌握与AI协作的常见模式和方法，例如：能够为AI提供清晰的函数签名和注释来生成实现代码。学会调试AI生成代码的常见问题，例如：识别并修正AI生成的代码中的语法错误或逻辑遗漏。开始建立与AI协作的个人工作流，例如：先用AI生成框架代码，然后手动填充业务逻辑。
3分：AI对话工程师
-
能够设计复杂的对话上下文引导AI，例如：提供完整的类结构和相关函数信息，让AI生成协调一致的代码。利用AI进行代码重构和质量提升，例如：用AI辅助将冗余代码重构为可复用的设计模式。建立系统的AI代码审查流程，例如：使用AI初步审查代码风格一致性，再进行人工深度审查。
4分：AI协作架构师
-
设计项目级的AI协作策略和规范，例如：制定团队的.cursorrules文件，确保AI生成代码符合项目标准。利用AI进行复杂系统的设计与迭代，例如：与AI协作从需求分析到模块设计的完整流程。优化人机协作的效率和产出质量，例如：建立AI编码效率的量化评估指标并持续优化。
5分：智能编程范式开创者
-
开创新的人机协作编程范式和方法论，例如：设计"人类负责策略，AI负责战术"的新型开发流程。构建自适应的人机编程协作系统，例如：开发能学习开发者编码习惯的个性化AI编程助手。引领团队向智能编程时代的转型，例如：建立组织级的AI编程能力评估和培养体系。
考察点14：对AI生成代码的深度审查与加固
-
评估内容：在代码审查环节，能够精准识别出由AI生成的代码中可能存在的逻辑缺陷、安全漏洞（如注入风险）、性能问题或对需求的误解，并提出具体、有效的修正建议。
-
能力体现：保持人类工程师的批判性思维和最终质量把关人的核心角色。
1-5级能力画像
1分：AI代码初级使用者
-
开始学习辨识AI生成代码的典型特征，例如：发现Copilot生成的代码常有过度通用的变量名如
data、result。进行基础的语法和格式检查，例如：像校对员一样检查AI代码的缩进、分号、括号匹配这些“表面功夫”。体验初级的代码审查实践，例如：发现AI生成的SQL查询缺少LIMIT子句，可能导致一次性拖垮数据库。
2分：AI代码逻辑审查员
-
能识别常见的逻辑错误和边界遗漏，例如：发现AI写的用户年龄校验是
if age > 18，漏了刚好18岁的“准成年人”。开始关注代码的安全隐患，例如：像安检员一样揪出AI生成的API接口里，用字符串拼接组SQL这种“危险品”。能够定位并修复简单缺陷，例如：AI生成的文件读取代码没关流，得手动加上finally块，避免文件句柄泄漏。
3分：AI代码质量工程师
-
系统性地审查AI代码的业务逻辑一致性，例如：像侦探一样对比需求文档，发现AI把“满100减20”做成了“每100减20”。深入挖掘潜在的性能瓶颈和安全漏洞，例如：发现AI在循环里调用了耗时且结果不变的数据库查询，得移出去。提供结构化的改进建议和模式重构，例如：建议将AI生成的一堆if-else分支，重构为清晰的策略模式。
4分：AI代码架构审计师
-
在架构层面审查AI生成的代码设计，例如：发现AI设计的微服务之间用同步HTTP高频调用，建议改为事件驱动。预判AI代码在复杂场景下的失效模式，例如：模拟高并发场景，发现AI写的缓存逻辑没考虑“缓存击穿”问题。建立团队级的AI代码审查标准和自动化工具链，例如：编写自定义的静态分析规则，自动捕捉AI常犯的特定错误模式。
5分：人机协作质量战略家
-
开创性地定义AI时代代码质量的评估与保障体系，例如：建立“AI代码可信度评分模型”，量化评估AI生成代码的可靠性。引领构建自适应、自修复的代码审查与加固系统，例如：开发能根据历史错误自动学习并预防同类问题的AI审查助手。在组织层面推动批判性思维与工程卓越的文化，例如：发起“AI代码挑错大赛”，培养整个团队对AI产出的深度审查习惯和能力。
考察点15：结构化提示工程与自动化评估
-
评估内容：为复杂的AI应用任务设计模块化、可复用的高级提示词模板（如思维链、Few-Shot样例），并建立一套自动化的评估流程与指标（如准确性、相关性、无害性），以数据驱动的方式持续迭代和优化提示词效果。
-
能力体现：以工程化的方法管理“人机对话”这一新界面，确保AI输出的稳定与可靠。
1-5级能力画像
1分：提示词初学者
-
开始学习与AI对话的基本技巧，例如：像学一门外语一样，尝试用不同的问法让ChatGPT写出更符合心意的代码。探索简单的提示模式，例如：发现加上“一步步思考”能让AI解题时给出中间步骤，像个耐心的老师。体验提示词对结果质量的影响，例如：对比“写个总结”和“用三句话总结核心观点”，发现后者更精炼。
2分：提示词实践者
-
能够为常见任务设计有效的提示模板，例如：为代码审查任务制作“角色+目标+格式”的三段式提示模板。使用Few-Shot样例提升输出稳定性，例如：给AI看两个好的产品描述例子，它就能批量生成风格统一的文案。建立基础的评估意识，例如：对比不同提示词生成的5个方案，凭感觉选个“看起来最好”的。
3分：提示词工程师
-
设计模块化、可组合的提示词系统，例如：像搭乐高一样，把“分析需求”、“生成方案”、“评估风险”拆成独立模块按需组合。建立量化的提示词评估体系，例如：定义“相关性分数”和“事实准确性”指标，用脚本自动评估生成内容。实现基于数据的提示词迭代优化，例如：记录每次提示词调整后的评估分数，找出效果提升最多的改进方向。
4分：提示词架构师
-
构建企业级的提示词管理与协作平台，例如：开发内部“提示词库”，团队可共享和复用经过验证的优质模板。设计复杂的多步推理与验证流程，例如：用“生成-验证-修正”循环，让AI自己检查代码中的潜在bug。实现提示词的自动化测试与监控，例如：在CI/CD流水线中加入提示词回归测试，防止优化后效果倒退。
5分：人机界面战略家
-
开创新一代的人机交互与协作范式，例如：设计“目标驱动、过程透明”的交互协议，让人能像指挥智能助手一样管理AI工作流。构建自演进、自优化的提示生态系统，例如：开发能根据任务反馈自动调整提示策略的AI智能体。定义行业级的提示工程标准与最佳实践，例如：主导制定企业智能化转型中的“人机对话质量白皮书”。
第六维：工程领导与系统权衡
核心价值：在复杂、模糊且资源受限的挑战中，领导团队定义问题、拆解路径并协同达成卓越成果。
考察点16：复杂模糊问题的系统性拆解
-
评估内容：面对一个定义不清的宏观挑战（如“提升平台用户体验”或“降低AI服务运营成本”），能够通过调研、分析与推理，将其拆解为一系列具体、可执行、可衡量的技术子任务或实验方向，并制定合理的优先级与实施路线图，并清楚地向 RASCI 角色沟通。
-
能力体现：在不确定性中创造清晰，将宏大愿景落地为可行计划，带动各方面协作高效率地完成任务。
1-5级能力画像
1分：问题识别者
-
能够识别出存在模糊性和复杂性的问题，例如：发现“系统太慢”是个真实但笼统的问题，需要进一步澄清。开始学习从多角度理解问题背景，例如：向用户和同事询问“慢”具体指什么场景，收集初步信息。尝试将大问题分解为更小的问题块，例如：把“提升体验”初步分解为“界面优化”和“性能优化”两个方向。
2分：问题分析者
-
能够通过调研厘清问题的具体维度，例如：通过日志分析发现，“慢”主要发生在晚高峰时的支付接口。将模糊目标转化为可衡量的指标，例如：将“提升体验”量化为“支付成功率提升至99.5%”和“平均响应时间降至200ms以内”。识别问题背后可能的核心驱动因素，例如：初步判断支付慢可能与数据库查询、第三方API或网络链路有关。
3分：方案架构师
-
系统性地将宏观问题拆解为具体、可执行的技术任务，例如：将“降低AI服务成本”拆解为“模型量化”、“推理引擎优化”、“资源调度策略更新”和“监控看板搭建”四个具体项目，并估算各自潜在节省。制定基于数据和优先级的实施路线图，例如：根据ROI分析，决定先实施“模型量化”（预估节省30%），再优化“资源调度”（预估再省15%）。能够清晰地向核心干系人（RASCI中的R和A）沟通计划和依据，例如：向技术负责人和产品经理展示拆解后的任务清单、预估收益和所需资源，获得支持。
4分：协作推动者
-
构建跨职能的解决方案框架并明确各方职责，例如：为“提升平台用户体验”项目制定RASCI矩阵，明确产品、设计、前端、后端、算法、运维各方的具体职责（谁负责、谁批准、谁支持、谁咨询、谁告知）。设计实验性方法验证假设并管理风险，例如：对“数据库索引优化”和“引入缓存”两个方案设计A/B测试，用数据决策。建立动态调整机制应对不确定性，例如：设定关键里程碑检查点，根据前期结果灵活调整后续任务优先级。
5分：战略拆解专家
-
开创复杂问题拆解与协作管理的新方法论，例如：设计并推广“模糊问题五步 5-why 拆解法”，成为团队标准流程。在组织层面建立从模糊战略到清晰执行的转化能力，例如：主导建立“技术战略室”，定期将公司级战略目标拆解为各部门可执行的技术项目。培养团队的系统性思维与高效协作文化，例如：通过工作坊和实战辅导，显著提升团队将“老板的一个想法”转化为“一张清晰项目图”的整体效率。
考察点17：团队内人机协作边界的定义与管理
-
评估内容：基于项目特点与团队能力，制定清晰的指南，界定在需求分析、设计、编码、测试等各个环节中，适合交由AI完成和必须由人工主导的工作边界，并用友善的语言和身先士卒的方式推动团队形成共识与最佳实践。
-
能力体现：在技术浪潮中保持理性，优化团队分工与协作模式。
1-5级能力画像
1分：AI应用观察者
-
开始观察AI在团队中的使用现状，例如：注意到有人用AI生成代码，有人用它写文档，但方式各异。思考AI可能带来的效率提升点，例如：觉得那些重复性的代码片段或许可以让AI试试。初步体验AI工具的辅助作用，例如：自己尝试用AI写注释或生成测试数据，感受其便利性。
2分：边界探索者
-
根据经验划分简单的人机分工，例如：规定“生成基础函数框架用AI，复杂业务逻辑自己写”。在小组内讨论AI使用的利弊，例如：在代码评审时，讨论某段AI生成的代码是否真的比手写更好。收集团队对AI工具的反馈，例如：询问同事们在哪些任务上觉得AI帮助最大，哪些地方反而添乱。
3分：规则制定者
-
为具体项目制定清晰的AI使用指南，例如：在项目启动时，就明确“API文档初稿由AI生成，但接口设计必须人工评审”。建立质量检查机制确保AI产出可靠，例如：规定所有AI生成的代码必须通过结对审查和额外的边界测试。以身作则推广最佳实践，例如：主动分享自己如何用AI高效完成设计文档，并附上提示词模板。
4分：协作架构师
-
设计覆盖研发全流程的人机协作框架，例如：创建智能工作流定义文件，自动分配AI和人工的任务。构建自维护的协作规范系统，例如：开发自动检测工具，当AI生成了超出边界的复杂业务逻辑时发出警报。建立动态演进的协作机制，例如：使用数据分析平台自动评估各环节人机协作效能，推荐边界调整方案。
5分：组织变革引领者
-
创造性地实现人机协作的无缝自动化，例如：构建智能代理系统，根据任务复杂度和风险等级，自动分派给AI或人工，并生成实时协作状态报告。开发代码即规范的智能治理体系，例如：将协作规则编码为可执行的检查点，取代传统的文档指南，确保规范被自动遵循。建立数据驱动的组织级AI效能优化，例如：创建AI协作效能仪表盘，通过实时数据指导团队优化协作模式，提升整体工程效率。
考察点18：技术指导与知识体系沉淀
-
评估内容：主动指导团队中的初级成员或合作伙伴，帮助他们完成具体技术任务、理解复杂系统原理；并通过撰写技术博客、设计内部培训、把文档变为自动质量门禁等方式，系统地沉淀和传播有价值的知识与经验。
-
能力体现：从个人贡献者成长为团队赋能者，扩大技术影响力的范围。
考察点19：对前沿实验性代码的快速集成与调试能力
-
评估内容：在缺乏完善文档的情况下，通过直接阅读和分析GitHub上的前沿项目或论文复现代码，成功解决其在特定环境下的编译、依赖或运行时问题，并将其集成到自有项目中。
-
能力体现：不畏惧技术“深水区”，具备强大的自主学习与问题攻克能力。
1-5级能力画像
1分：知识分享初学者
-
开始尝试向同事解释自己完成的技术任务，例如：在组会上简单介绍上周修复的一个Bug是如何解决的。有意识记录工作中遇到的技术问题，例如：在个人笔记里写下某个配置错误的排查过程。学习借鉴他人的分享方式，例如：阅读团队内的技术文档，学习如何清晰地描述技术方案。
2分：主动指导者
-
能够指导初级成员完成具体技术任务，例如：带领实习生一步步完成一个API接口的开发和测试。开始系统整理自己的技术经验，例如：将常见的部署问题整理成FAQ文档分享给团队。参与团队内的知识分享活动，例如：在技术分享会上做一个15分钟的主题分享。
3分：体系构建者
-
设计结构化的培训材料帮助团队成长，例如：为新员工设计为期两周的“微服务架构上手实战”培训课程。建立团队内部的知识管理机制，例如：推动建立团队的Confluence知识库，制定文档规范和更新流程。通过技术博客扩大影响力，例如：将解决的技术难题写成博客公开发布，获得行业同行的认可。
4分：效能赋能者
-
构建自动化知识应用系统，例如：开发代码审查机器人，将最佳实践编码为自动检查规则，在提交时实时指导开发者。**创建智能知识检索与推荐系统，例如：建立内部问答AI，能基于历史问题和文档，自动回答常见技术疑问。**建立技术能力评估与培养体系，例如：设计团队技术能力雷达图，为每位成员制定个性化成长路径。
5分：组织智慧架构师
-
开创自演进的知识自动化生态，例如：构建“代码即知识”系统，将技术决策直接编码为架构约束，自动在后续开发中强制执行。**实现知识资产的智能治理与增值，例如：开发智能分析平台，自动识别团队知识缺口，推荐学习材料和培训主题。**引领组织级的技术文化建设，例如：建立技术影响力评估模型，将知识沉淀和传播能力纳入晋升考核体系。
考察点20：极端条件下的底层问题解决与核心构建能力
-
评估内容：在脱离AI辅助、网络资源和现代IDE的模拟极限环境下，能够在短时间内，仅凭对编程语言和系统原理的深刻理解，完成从搭建基础开发环境到手动实现关键算法或核心模块的一系列挑战。这体现了对技术栈底层原理的掌握，以及在资源枯竭时仍能交付价值的坚韧能力。
-
能力体现：回归工程本质的“硬核”功底，是应对一切技术不确定性的终极底气，也是工程师 “can do” 精神的体现，在一些重要项目中有巨大的现实意义。
1-5级能力画像
1分：基础环境搭建学习者
-
开始学习脱离高级工具的独立操作，例如：在只有基本Linux环境的机器上，学习手动配置编译器和依赖库。理解开发工具链的基础组成部分，例如：了解从源代码到可执行文件的完整编译过程及各阶段作用。尝试在受限环境下完成简单任务，例如：在无网络情况下，手动编写并编译一个简单的“Hello World”程序。
2分：受限环境实践者
-
能在基础环境下完成小型项目构建，例如：在仅有文本编辑器和命令行编译器的环境下，开发一个简单的文件处理工具。掌握核心编程语言的手写实现能力，例如：能够不依赖IDE自动补全，手写完整的类定义和算法实现。开始积累底层调试经验，例如：通过分析汇编代码或核心转储文件，定位简单的内存访问错误。
3分：极限挑战应对者
-
能在严格受限条件下交付核心功能，例如：在离线环境中，48小时内从零搭建开发环境并实现一个通信协议的关键编解码模块。深入理解系统底层原理以解决问题，例如：通过理解TCP/IP协议栈，在缺少高级网络库的情况下手动实现可靠数据传输。建立系统性的“脱网”开发流程，例如：制定离线环境下的代码组织、手动测试和验证的标准流程。
4分：硬核工程专家
-
能设计并实现自包含的基础设施工具链，例如：在隔离环境中，手动实现轻量级构建系统和单元测试框架以支持项目持续开发。**在资源极度匮乏时展现创新解决方案，例如：面对一个仅有残缺日志和异常堆栈的线上崩溃，能通过构造最小复现环境，逆向推测出是并发场景下的锁竞争问题，并设计无锁数据结构予以解决。将极限能力转化为团队的核心资产，例如：主导制定高可靠性场景下的“去依赖”开发指南和应急构建方案，提升团队整体韧性。
5分：工程确定性创造者
-
开创并定义新一代的“确定性工程”方法论，例如：构建数学模型和工具链，可证明在给定极端约束下，关键系统仍能被正确构建和验证。**构建自验证、自适应的核心系统构建框架，例如：当核心数据库在凌晨宕机且监控缺失时，能仅根据崩溃现场的内存映像和部分I/O日志，像法医一样重建事故时间线，准确判断根因是存储引擎的特定页分裂异常，并据此热修复生产系统。**将“硬核”能力打造为组织级战略优势，例如：在涉及国家安全、金融核心或太空探索等关键领域，建立世界领先的极端环境工程技术标准和人才体系，让“Can Do”精神成为核心竞争力。
===== 2024 年前的版本 ======
第 0 部分：基本数据结构和算法问题，请看《编程之美》 等书籍； 如果想了解应聘的门道，那请看 如何花两年的时间面试一个人 。
第一部分：硬的问题。要在找工作的时候说服别人你是适合这个工作的， 那就要搞清楚对方期待什么东西，自信地展现出你的价值和能力。 (这个列表也可以说是 - 面试中最关键的问题)
下面还有更详细的调查表，适合大家自评，或者在上课前后衡量并找出自己的强项和薄弱环节：
对于一个具体的语言, 例如Java， 你掌握了多少呢？能通过实例来回答下面的每一个问题么？
（图片来源于微博 @聊聊架构）
第二部分：软的问题，在成长路上学到了什么？
工程师的能力和成长路径都有多种选择，没有一定之规。IT 行业变化也很快，例如 Swift 语言刚出来两年的时候， 一些招聘广告上就要求 “有 3 年以上 Swift 实际开发经验”， 那么，一个写了 5 年 C++，学了三个月最新版本Swift 语言的工程师能算够格么？ 除了每一门具体的语言和工具， 工程师在行业中不断磨练，和各种人合作，参与了各类开发活动，一个优秀工程师是否会培养出独立于具体语言的 “工程师能力”？ 如果一个项目领导带领团队做了几年的项目，团队中的工程师用各种编程语言解决具体问题， 他和不做领导的工程师相比有什么特别的能力？他在每一个具体的编程语言上可能都不如某个工程师， 那他的独特价值是什么？
我们把这些叫做 Soft Skill， 软的能力。
很多时候，我们希望获得一些可以跨专业衡量和交换的数字，这样便于比较，所以下面的的每项回答都可以换算为一个分数， 以满足部分读者的需求：
1. 保持高标准，不要受制于破窗理论(broken windows theory)[i]。
当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。”
a) 从来没听说过； b) 我就是这样随便过来的； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
2. 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了[ii]。
a) 不懂啥是靠谱的设计； b) 随便应付一下即可； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
3. 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。
a) 从来不看书； b) 看了就忘； c) 有时分享。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
4. DRY （Don't Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。
a) 从来没听说过； b) 听说过，但是认为意思不大； c) 这要讲场合。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
5. 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。
a) 从来没听说过； b) 出了问题再说吧； c) 想做，但是不知道怎么衡量效果。 d) 能够在多种语言和架构中做到 e) 不但主动做， 还会影响同事一起做好
6. 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。
a) 从来没听说过； b) 把原型直接用于产品，不然就浪费了； c) 不用原型，一直在产品中直接改。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
7. 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。
a) 从来没听说过； b) 按我的想法设计，用户以后会适应的； c) 大概同意，但是怎么接近用户呢？ d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
8. 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。
a) 做完了，就知道花费了，不用事先估计； b) 大概估一下，不必在意时间 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
9. 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。
a) 一直用鼠标和GUI； b) 到时候问牛人； c) 正在学习命令行工具。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
10. 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。
a) 只用老师教的一个； b) 随意； c) 没有任何定制。 d) 会定制，并且分享给其他人 e) 还会学习和使用各种编辑器的扩展。
11. 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。
a) 从来没听说过； b) 模式没用； c) 每写100行程序，我就尽量用一个模式。 d)有实际使用的经验 e) 能用具体代码说明模式的利弊
12. 代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。
a) 从来没听说过； b) 用QQ，u盘即可； c) 领导要求才用。 d) 经常用 e) 不但主动做， 还会影响同事一起做好
13. 在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log.
a) 从来没听说过； b) 只会printf； c) 加log 太麻烦，我的代码不会有bug 的。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
14. 重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。
a) 从来没听说过； b) 太麻烦，不用； c) 想用，但没有时间。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
15. 只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。
a) 从来没听说过； b) 抓住所有异常 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
16. 善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源。
a) 从来没听说过； b) 随缘； c) 有时这样做。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
17. 当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。
a) 从来没听说过； b) 没有实践的机会； c) 代码都在一起比较好管理。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
18. 把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。
a) 从来没听说过； b) 拷贝代码过来用也可以 c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
19. 在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。
a) 从来没听说过； b) 并行不会出错的； c) 任何代码都应支持并行。 d) 考虑在适当的层次支持并行 e) 不但主动做， 还会影响同事一起做好
20. 在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。
a) 代码都在一起比较好改； b) 随缘啦； c) 没搞清楚啥是V，啥是M。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
21. 重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。
a) 从来没听说过； b) 我的数据量不大，无所谓； c) 不会有效率问题的，现在CPU 都快了。 d) 主动测试程序效率，以验证估算 e) 不但主动做， 还会影响同事一起做好
22. 在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。
a) 从来没听说过； b) 想用，但不知道工具 c) 主要靠肉眼观察算法效率。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
23. 经常重构代码，同时注意要解决问题的根源。
a) 从来没听说过； b) 任何修改都可以叫重构； c) 每天应该重构两次。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
24. 在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。
a) 从来没听说过； b) 我的代码不会出问题的； c) 项目没有安排时间，我也没有提这事。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
25. 代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。
a) 从来没听说过； b) 从来不看那些代码； c) 那些代码没有bug。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
26. 和一个实际的用户一起使用软件，获得第一手反馈。
a) 从来没听说过； b) 用户太蠢，不值得听反馈； c) 想做但是没有机会。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
27. 在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误。
a) 没听说过； b) 不必这么麻烦； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
28. 如果测试没有做完，那么开发也没有做完。
a) 从来没听说过； b) 签入代码，就是做完了； c) 。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
29. 适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。
a) 从来没听说过； b) 覆盖20% 就好了； c) 要覆盖至少60%。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
30. 如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。
a) 从来没听说过； b) 每个bug都是特殊的； c) 测试用例不值得加 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
31. 测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误?
a) 从来没听说过； b) 如果有问题，用户会报告的，我们不用测这些； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
32. （带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。
a) 从来没听说过； b) 我们决定用户的期望； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
33. （带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。
a) 从来没听说过； b) 用户不说的，我们不做； c) 如果有明确要求，我可以做好。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
34. （带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。
a) 从来没听说过； b) 都记在我脑子里； c) 大家看代码就好 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
35. （带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。
a) 从来没听说过； b) 我们没有休假的，没关系； c) 出了问题再说 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
36. （带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。
a) 都听领导的； b) 团队严肃紧张最好； c) 不必尝试，失败的可能性太大。 d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
37. （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。
a) 没有时间总结，直接做下一版； b) 总结用处不大； c) 如果上级有要求，就做一下； d) 一直主动这样做 e) 不但主动做， 还会影响同事一起做好
38. （带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？
a) 我没看见矛盾。 b) 和稀泥，过得去就行 ； c) 如果没有捅到上级那里，就打哈哈，希望他们自己搞定； d) 有明确和一致的处理矛盾的原则 e) 不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底
[ii] Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，见到问题，就要解决问题，但是也不要沉溺于无法挽回的事情中。参见：http://www.menk.com/blog/archives/2006/11/20/jim-barksdales-rules-of-snakes 以及 http://www.celebrazio.net/jimb/15.html
浙公网安备 33010602011771号