内容
slogon: 大模型正在重新定义软件
主题
AI 应用开发实践
豆包 MarsCode 在 AI Coding 的探索与实践
-
Ai Coding的诉求：
-
代码补全
- 主要原理：基于各种上下文 构造提示词 → 模型推理 → 后置过滤 → 补全代码提示
- 测评体系：开源代码和内部代码具有较大的差异，需要引入自研评测集
- 训练优化：利用GPT对项目打分，并以此生成数据训练自研模型
- 性能优化：补全内容越少，用户接受度越高
-
代码问答(代码理解)
- 原理：将question与代码知识图谱(CKG) 一起喂给GPT，最终得到答案
-
代码修复
-
探索安全边界：出海合规与大模型实践
-
安全运营挑战
- 精准识别
- 智能决策
- 快速响应
-
大模型在安全运营的应用
- 安全事件翻译
- 结构化输出
- 战报日报总结
- 漏洞挖掘增强
-
当前存在的问题：重分析、轻决策、零执行
-
模型决策
-
方案：
- 提前生成剧本，可以理解为一系列提前的预案和动作
- 让模型基于当前的事件来选择合适的剧本，并自动开始执行
-
风险
- 决策失误
- 操作失误
-
降低风险的实践
- 先通知再执行
- 先风评再推荐
- 随时切换操作模式
-
演进式架构
-
初创阶段：使用开源项目完成极简开发
-
问题：
- 用户量级增长，带来了性能、功能、数据规模、产品形态
-
大前端架构
-
1.0：参考开源项目
-
2.0 重新思考「第一性原理」
-
渐进路线：阶段性交付，整体达到完全自研目标
-
Electron：渐进式客户端架构，原生语言重新实现编辑器内容。eclectron参考：juejin.cn/post/719724…
-
三端合一：将native编译到 WASM。wasm参考：www.infoq.cn/article/lwl…
-
提效
- ai 生成 单测. 场景用例相对固定，可以使用单测保证。有点类似于motiff ：yuanlearning.zhenguanyu.com/#/front/cou…
- ai 生成 open office xml
-
-
-
后端架构
-
0.X 自由生长
-
1.0 ：语言统一收敛到go、上云、引入单元测试
-
2.0 ：
- 标准化：固定工程目录，统一框架
- 微服务：轻重分离、架构分层
- 工具化
-
3.0：DevOps
- 主干开发
- 中间件接口化
- 引入编辑后台
-
4.0：异地多活
-
蚂蚁：Koupleless 模块化，单体应用到微服务到 Serverless 的可演进架构
-
问题：
- 研发效率低：认知成本高，业务研发需要感知底层
- 协作与资源成本：小应用过多，大应用过大
- 合理拆分困难：业务发展&应用形态 敏捷度不一致
-
KoupleLess框架
-
屏蔽基础设施：纵向下沉基础设施
-
细化研发运维粒度：大应用可以切分多模块，小应用可以合并部署 (不确定这个的具体收益？)
- 模块：每个模块有独立的springContext和类加载器，构建产物为jar，可以热部署
-
平滑演进：模块架构是单体架构和微服务架构之间的一个权衡
-
-
微服务化演进
- 微服务架构：独立、完备、内聚、自治
-
服务分层
-
数据建模：对稿件进行建模
-
生产加工流水线：产出内容生产平台。抽象工作流程框架
-
数据模式的更换：CQRS(参考：www.infoq.cn/article/wdl…)
- 适配业务需要，新的存储模型选择，数据迁移痛点
-
稿件业务的异步模型流程
- 异步场景数据一致性：产出异步事件治理平台
-
效率问题：归一化指标，稿件生产效率
-
可观测性：
- 全链路 trace
- 实时数据ETL
- 异动感知
-
-
多活、FaaS 化和混合云
-
同城/异地多活
-
转码资源调度的 FaaS 化
-
一点小想法：
- 关于算力资源：mysql的物理机上可以建立多个集群，多个实例，用到了其中的存储资源/计算资源。我们当前无论是合并部署，还是当前的单服务部署，都存在资源的大量浪费。应该可以做到，业务方提诉求，不感知具体的部署产物。由运维统一支持多服务和机器的调度？service mesh: www.cnblogs.com/guoxiaoyu/p…
- 报告业务相关的逻辑 或许 更适合CQRS ?
大模型基础设施与算力优化
- AI集群性能影响因素：集群总算力 = 单芯片算力 *集群规模 ** 算力效率 * 可用率
命题：在固定集群资源条件下，单点+分布式推理，提升集群处理大规模请求的能力
-
大规模推理挑战
-
优雅的集群过载：成本下降了20倍
- 更低成本 = 更省的模型结构 + 更便宜的硬件
-
超长上下文性能挑战
-
故障定位与自动运维
-
-
单点性能优化
- 混合并行策略
- 长上下文推理优化
- 分离式架构 Mooncake
- 设计场景 —— SLO vs MFU - 分离式架构设计
- 集群调度策略、热点均衡
- 开源计划
- 未来展望 - 硬件能力展望
- 更细粒度的池化分离
- 分离式内存系统
新技术浪潮下的大前端机遇与挑战
-
历程和背景
-
鸿蒙对比安卓：生态在发展。开发工具为arkTs，c+=，devEco等
-
应用架构层级：三层架构
- 产品定制层：手机、平板等
- 基础特性层：Feature层。布局组件、多媒体空间、反馈套件
- 公共能力层：一多框架，网络请求，工具类
-
性能指标：慢函数
- 关注「过程时长」、流畅性
-
-
OS能力 & 优化实践
-
IO场景：并行、多线程、异步
- worker，TaskPool，Sendable(数据传输)
-
冷启动&首刷类场景优化
- 懒加载、动态组件、组件复用池
-
滑动类场景：推荐页、个人页
- prefetcher
-
性能热点问题：静态代码检测
-
UI重载场景：分帧
-
-
鸿蒙OS分析工具
- 主观测评：脚本化的录屏和分帧
- 性能分析工具：IDE-Profiler
- 性能场景测试工具：DevEco Testing
下一代 Data for AI 技术架构
-
LLM场景数据湖现状
-
数据特点：
- 多数据类型：结构化、非结构化
- 非结构化数据越来越多：web语料数据、RAG知识库 需要PB级空间
-
经典数据湖架构：
-
现状
- 统一存储底座：数据为 hdfs/对象 存储(包括 结构化、半结构化、非结构化)，结构化meta存储在HMS
- 数仓生态：HMS进行元数据管理，Table Formation 支持Table高级特性
- AI/ML 场景缺乏统一方案：自行管理，分别解决接口、IO问题
-
问题：
- data: I/O 瓶颈
- meta: 元数据管理能力薄弱，包括catalog、dataset 管理
-
-
-
LLM对数据湖的挑战
-
Data层面：对象存储I/O痛点：
- 语义隔离
- 大量小文件list
- 带宽拓展性：对高效读、高吞吐写有要求
- 延迟：稳定低延迟的拉数据集和 写checkPoint
-
Meta层面：通用数据湖痛点
-
catalog 功能薄弱
- HMS 运维：天然具备拓展性问题
- 非结构化数据支持：无法应对非结构化和半结构化数据
- 数据治理：无法统一、也存在冷热分层等问题
- AI生态：HMS无法管理AI数据集
-
DataSet (半结构化、非结构化数据)的要求：
- ACID
- Tag管理、数据集构造、容易分享、AI生态友好
-
-
-
火山数据湖的解决方案：
-
Data
-
对象存储I/O瓶颈：
- proton透明加速：增加直连模式、缓存集群、本地缓存多种模式
- 文件系统语义：统一命名规范
- 小文件list: 提供分层命名空间的能力(HNS)，提供对目录操作的各种能力
- 吞吐优化：包括读/写优化。主要手段为：多级缓存，内存池，分级写，异步写等模式
-
-
Meta
-
catalog
- LAS Catalog：全托管服务，开发API设计、统一数据治理
-
dataset
- LAS Volume：包括元数据表和数据对象两部分。元数据表记录了数据集的文件，以及这些文件的tag，并存储在iceberg中，解决dataset痛点问题
-
-
[小米] AGI 时代统一数据目录的设计与实践
-
AGI 时代的数据需求
-
大模型开发应用的核心：数据
- 处理流程：输入数据→ 加工数据→ 模型→ 向量 → 提示词
- 数据管理：数据发现、数据血缘、数据治理、权限控制
-
-
现有技术的挑战
-
数据被锁定在不同的数据源中
- 数据湖、数据仓库、消息队列、向量数据库、share drive
-
数据被地域分割：
- 企业的多云多域架构
- 数据管制的限制
-
数据被组织分割
-
水面下的数据问题：数据连接、主权、元数据增强、数据发现、数据分类、生命周期管理
-
-
Gravitino：统一元数据底座
- 元数据湖：统一的数据/AI 目录
- 抽象与实现统一的数据模型，来涵盖结构化和非结构化数据
- 实现统一的异构、跨域、跨云的数据视图
- 构建统一的权限模型来统一管理云上和云下数据
- 构建一个高效且通用的 Data Agent，来支持基于文档数据库与海量数据湖的混合语义检索
AI 重塑技术工作流程
-
大模型使能运维总体规划
-
诉求：高门槛、高价值、高人力场景
-
TOP需求：
- 问答式运维信息查询
- 运维知识检索
- 故障信息总结生成
- 故障预案推荐
- 实践解决方案生成
-
目标：建设全面辅助问答交互能力，打造运维副驾驶
- 多触点构建：多种触点模式，支持web，welink机器人，以及运维工具系统集成
- 运维copilot stack：端到端对话、意图理解、agent和tools建设、运维大模型集成
- 运维大小模型协同计算：小模型聚焦确定性量化分析，大模型注重内容理解生成
- 高质量运维知识语料中心：围绕运维知识数据收集、知识规范、知识管理、运维语料标注
-
-
运维大模型应用难点和解法
-
4大难点：
- 语料少、质量差
- 大模型幻觉
- 大模型逻辑推理难
- 业务应用难，见效慢
-
6大方案：
-
运维语料数据增强：
- 构建冷启动原始语料集：故障文档、真实检索行为、模拟问答
- 通过提示词模板生成语料：采用大模型合成数据快速构建语料数据
- 构建真实语料意图标注能力，持续进行运维语料的有效治理
-
全流程知识治理：如何选择？如何治理？如何管理？如何消费
- 确定知识地图。产品文档、流程规范、案例库、故障预案
- 明确知识owner和责任人。制定领域知识管理规范、管理生命周期、及时更新
- 统一知识管理和存储。
- 知识消费管理。问题改写+RAG+知识解析+badcase治理
-
确定性运维意图理解：精确识别意图，解决幻觉问题
- 多层路由、简化多场景运维意图管理。多agent方案，如知识问答agent、故障处理agent
- 意图路由层：意图快速分类路由。结合文本相似分类小模型和大模型
- 意图纠偏层：结合badcase实现小概率错误的意图精准纠偏
-
增强RAG实践：从知识问答改写到多路知识检索全面提升。
- 事前自动提取问题摘要。意图改写，结合提示词实现问题标准化和分类改写、明确检索意图
- 事后多路检索提升大模型检索准确率。结合问答对，向量检索和关键词检索，实现多路由检索
-
基于确定性决策实现大小模型协同故障诊断方案：故障诊断等环节涉及较多部分，端到端场景的推理比较难
- 借助思维链COT，结合故障案例，确认故障分析步骤
- 结合编排框架，实现执行链的确定性编排，降低复杂任务的推理和决策难度
- 组合故障大小模型。小模型精确诊断定界(数据库诊断小模型、MQ诊断小模型 等等)、大模型确认预案推荐和总结
-
多触点集成方案，提升业务生产力：改变交互行为，提高运维生产力
- 流程嵌入，运维助手无缝融合
- 副操作界面，copilot辅助。运维工具界面，运维助手
- 统一运维助手web端，新交互
-
-
![]( "黄鑫 > QCon 2024 上海站 概览 > WX20241124-224449.png")
-
研发提效探索
- 开发最耗时的活动：编写代码，理解代码
- 使用最多的功能：代码补全
-
智能研发发展路线
-
copilot + chat ：传统效能平台快速集成 AI 能力。在现有产品功能上做智能化升级
-
copilot + agent：结合平台能力进行智能化改造
-
AI 原生：用户无需主动触发AI功能，原有功能嵌入AI能力
- 代码补全
- 生成注释
- 解释代码
- 代码分析
- 生成测试
- 智能问答
-
-
关键技术与难点：代码底座大模型 != 产品落地
-
算法关键与难点
- 代码底座大模型: 预训练+微调
- 模型填空：fill in the middle。主要解决代码生成不完整问题，用于结合上下文进行完形填空
- 自适应语法粒度：需要程序分析
- 仓库级感知：需要repoFuse仓库级补全
- 推理部署：时间问题
-
工程关键与难点
-
触发时机
- HPF 抢占式队列 (高优先级调度)
- 上下文太少不触发
- 缓存
- 动态delay
-
上下文边界：需要解决幻觉问题。包含两个大的阶段：文件级、仓库级
- 检索召回：RAG + 程序分析能力强化上下文。包括文件上下文、相似代码、相关代码、重要性排序、prompt构造
- 引用链路追踪
- 代码解析/压缩
-
实时+耗时
- 本地向量/索引：通过AST分析以及代码切分，构建file、函数、chuck等多个维护的索引库。包含文本索引、KV索引
- 严格限制资源的低侵入构建
- 20ms以下仓库检索
-
效果优化
- 低收益判断
- few-shot
- 校验后置策略
-
多模型/多策略
- ab
-
-
-
未来方向思考
-
人工智能应用阶段：tool → chat bot → copilot → agent → intelligence
-
腾讯云 - AI重塑技术流程：下半场的破局之道
-
为什么是下半场？
- 上半场：初步的成本削减和效率提升措施。产品聚焦、人员精简、异地子公司
- 下半场：AI领航，保战力，提战力
-
保持团队战力：知识传承。知识库+RAG+AI
- 沉淀知识：AI总结助手
- 检索知识
- 应用知识
-
提升团队战力：提建议到给代码
-
未来打造团队战力
- Value: 价值。定义的prompt和知识库
- Organization: 组织。POC 和 工单知识飞轮
- Rareness: 稀缺性。工单/POC 专家知识，终端专家知识库
- Inimitability: 难模仿。工单处理流程，性能优化流程
线上可靠性工程
-
蚂蚁故障体系：
-
故障定义：无论什么原因导致的 用户服务体验下降、服务中断、服务品质下降
-
故障等级：
- 考虑因素：客诉、资损、用户量级、错误量级、区分场景
- 如何保鲜：定期review、业务/架构 有调整后及时更新
-
故障序列：根据故障原因和时间影响对故障进行分类
-
GOC故障点：明确关键的服务、功能、接口、结果以及评价其产生异常后的影响情况
-
故障处理流程：异常发现→ 故障预判→ 故障处理→ 故障恢复→ 事后跟踪
-
故障数据运营机制：
-
数字化运营：
- 结果指标：故障数量、重大故障数量、故障监控发现率、故障30分钟恢复率
- 过程指标：1-5-10符合度(1分钟发现，5分钟处置，10分钟恢复)、GOC场景数、故障密度、故障action完结率
-
文化运营：奖惩机制、新人培训、日常宣推、故障管理制度、专门组织跟进
-
-
-
蚂蚁应急体系介绍：
-
应急角色：
-
值班长：负责全站故障指挥、应急协同、评估应急流程中的风险并提炼解决方案
-
一级部门应急小组：
- 部分值班长：风险场景识别、监控覆盖等，负责本部门下的指挥和应急协同
- 部门开发、质量、SRE：故障跟进及处理
- 稳定性一号位：应急止血、后续action跟进
- 部门GOC：本部门的故障复盘组织，action分发
-
-
应急快恢架构：端智能异常告警 → 值班长响应 → 根因定位/变更定位 → 业务预案/运维容灾
-
应急分析与评价：SRE为应急效果负责，48h内完成应急复盘
-
应急止血方式：业务预案 → 基础运维操作 → 容灾切流 → 变更回滚
-
-
线上故障的生命周期：在一个平台里干所有事情
- GOC故障定义 → 指标度量 → 故障发生及处理(包含时间线和处理过程) → 故障信息收集 → 故障复盘 → 故障action
-
AI 助力：结合复盘文档、监控查询、变更记录、日志记录等 构造agen
-
新形势下稳定性挑战：
-
行业面临的稳定性挑战：
- 业务复杂性，多样性
- 基础设施的故障和隐患
-
-
混沌演练：提供故障演练和容灾演练的全覆盖，围绕轻量级演练思路，从组织、流程、技术等角度切入
- 手段：混沌实验、强弱依赖演练、预案演练、多活演练、突袭演练
- 流程：标准化演练流程
- 技术：丰富观测能力，自动化演练能力，自动化回收结果
- 组织：组织的协同机制，强化收益认知
-
轻量级容灾演练体系
-
组织文化：
- 组织架构支撑：建立安全生产委员会
- 制度建设：容灾架构规范，演练章程
- 文化宣导：培训、技术分享、孤岛行动
-
流程支撑：
- 参与方：稳定性负责人、SRE、研发、测试
- 执行流程：业务梳理→ 方案确认 → 指定演练范围→ 配置演练流程→ 关联验证场景→ 演练执行→演练恢复 →常态化演练 →待办跟进
- 演练生命周期：实验构建 → 非生产环境演练 → 生产环境演练→ 常态化演练
-
技术支撑
- 演练协议标准化：混沌原子故障实现方式各异，切自研成本高。抽象统一的描述模型，对外兼容，对内统一。
- 故障引擎自研化：开源引擎逐步暴露了一些问题 → 转为自研
- 实验参数精简化：参数配置成本较高。过程式→ 声明式，所见即所得
- 演练覆盖全面化：短时间进入可演练状态
- 演练过程可视化：解决演练对象类型多，指标平台多，上下游影响难感知等事情。统一标准对象描述、抽象指标获取行为、关联演练对象的上下游告警
- 演练流程自动化：场景自动验证，演练自动执行，预期自动验证
-
-
业务场景演练实践
- 演练协同一体：协同线上化，统一到一个面板。流程为：演练配置→ 演练执行→ 演练恢复→ 验收报告
- 可用区级断网容灾演练：确保可用区级别故障来临时，业务和基础架构服务具备逃生和容灾能力
- 集成测试演练：CI/CD流程接入演练，QA可以编排故障场景
创新产品设计
-
问题：AI很强大，但是没啥用
-
原因：思考的出发点错了，不能按照既有思维来定义产品
-
颠覆性技术的思考方式：利用技术核心特性，去做之前做不到的事情
- GPT：实时生成
- Midjouney：基于文字描述实时生成
- Tripo: 根据文字描述或图片实时生成
-
示例：用AI实时生成3D模型为核心玩法，设计游戏规则
- 围绕AI特性构建全新的游戏体验
- 基于生成式，做随意建设的世界
-
结论：不要用“改进现有内容”的眼光去看待新技术，回到内容本源，重新思考新技术特性的应用方法
与时俱进的团队管理
-
技术与管理的关系
-
关系
- 职场演变：要求有优秀的管理能力，且保持技术敏锐度应对挑战
- 技术管理交汇：能把技术专长与管理能力相结合
- 职业发展趋势：如何在不放弃技术专长的情况下，成功转型管理者
- 个人与公司双向需求：公司需要能掌控技术复杂性的管理者，并推动创新和竞争优势
-
核心职责
-
技术角色：
- 技术知识和技能
- 设计、开发、实施和维护技术解决方案
- 解决复杂技术问题，提供新的解决方案
- 系统架构、数据分析等复杂的具体技术任务
-
管理角色：
- 负责团队和项目的规划、协调和执行
- 管理团队资源、包括人力、时间、预算
- 指定战略和政策，推动团队朝目标前进
- 关注团队发展，绩效以及团队合作
-
-
技能要求和工作重点
-
技术角色：
- 技术洁癖
- 专业精通
- 持续学习和适应新技术
- 以技术问题的解决为核心，注重细节和准确性
- 关注产品性能、执行效率、技术创新
-
管理角色：
- 出色的沟通和人际交往
- 领导力和决策能力
- 项目管理和组织协调能力
- 以团队管理和项目的成功为核心，注重整体视角
- 关注目标的实现、团队的协作发展
-
-
评估标准和发展路径
-
技术角色：
- 技术能力、代码质量、持续学习
- 高级技术专家、架构师、技术顾问
- 深化技术专长、可能参与技术研究和创新研发
-
管理角色
- 项目成功率、战略目标的实现
- 领导能力和团队满意度
- 发展偏向于更高管理职位：部门经理、高级总监
- 扩大管理范围和战略思维，培养业务的前瞻性
-
-
-
叠加管理的重要性：培养复合型人才
-
综合决策能力：
- 快速变化的技术环境：掌握并落地最新技术
- 多变的商业需求：技术方案与业务目标保持一致
- 数据驱动的决策：具备分析和处理数据的能力。将数据转化为业务战略，提高决策精准性
- 风险评估与管理：前瞻性的风险评估
-
创新优势
- 推动技术创新
- 全局视野：理解业务战略和掌握市场动态
- 保持竞争优势：将技术创新转化为商业价值
- 系统化创新管理：以系统化的方式组织创新过程，提升创新的效率和效果
-
组织战略和人才培养：
- 组织战略：保证战略实施与正确执行
- 提升团队协作能力
- 人才与团队：识别成员的优势和不足，优化团队结构和工作流程
- 职业发展：既懂技术又懂管理的复合型人才
-
-
技术与管理的平衡
-
失衡：
- 盲目追求新技术
- 过分依赖技术驱动产品开发：可能导致产品功能与用户需求不符
- 技术重构导致项目失败：缺乏清晰的目标和里程碑，导致进度不明确，忽略了团队间的沟通和协作
- 忽视团队管理的意识：忽视团队成员的激励和认可，导致成员感到被忽视。缺乏合理的工作计划和资源分配，导致成员过度劳累
-
技术细节决定成败：
- 敏捷开发流于表面：站会的流程化、技术债务的积累、充分的技术评审和代码revie，代码质量下降，bug频现
- 滥用项目管理工具：过度依赖项目管理工具，过分追求线上流程
- 技术选型的失败：没做好项目中的技术监督和指导，过度依赖外部资源，忽视了内部团队的技术培养和发展
- 安全性的忽视：缺乏充分的安全性评估和测试
-
-
面对的挑战：
-
角色转变：
-
认知转变：从更高层次看待问题，补充管理理论并实践，加强与团队成员的沟通
-
时间管理：
- 平衡技术工作和管理职责，避免过多干预具体细节
- 参加必要的会议，严格控制时间
- 适当的任务委托给合适的成员
- 合理利用项目管理工具来追踪项目进度和任务分配，确保所有工作竟然有序
-
-
技术与业务的平衡
-
增加对业务的理解：
- 掌握行业术语和动态，了解行业的运作模式、市场趋势和竞争态势
- 技术方案以解决客户需求为导向
- 掌握财务概念：成本控制，预算管理，roi
-
团队资源分配：
- 分析需求的时间预算优先级，确认资源分配机制
- 制定成员的技能矩阵
- 资源有限的情况下，优先业务目标最有贡献的项目或任务
- 与市场、销售、运营等部门建立良好的沟通渠道，与其他部门的目标也保持一致
-
-
项目管理
-
风险管理：
- 项目启动阶段，全面识别项目风险
- 定期审查和更新风险登记表
- 预防措施和应急计划
- 风险管理培训
-
跨部门协作
- 理解其他部门的角色和职责
- 注重倾听、理解他人的观点和诉求
- 沟通上使用清晰、简洁的语言
- 平衡不同部门的收益
- 接受反馈，对反馈持开放态度
- 项目初始时明确部门责任和边界
-
-
绩效管理
- 公平公正，不能主观偏见
- 避免大锅饭
- 目标不明确、评估可能会变的模糊
- 技术专家更习惯技术沟通、绩效需要更高水平的人际沟通
- 评估结果与员工的自我评价不一致时，他们可能对评价结果感到不满意
-
-
面临挑战：
- 职业安全焦虑：降本增效、被 AI 替代
- 竞争加剧
-
AI时代不变的内容
-
工程师文化：责任担当、追求极致、终身学习、勇于创新、协同共赢
-
两个能力：
- 设计能力：代码易读、文档话、代码易改
- 工程能力：敏捷(敏捷开发、及时改善)、敢改(还技术债、单元测试、持续重构)、七化(规范化、流程化、工具化、自动化、产品化、文档话、现代化)
-
-
自我成长：
-
精神文明远远落后于物质文明
- 精神文明：自我发展
- 物质文明：职业发展
-
不同的阶段：需要不断寻找真自我。尊重自身特点和喜好、言行一致、低精神内耗
-
自我发展的规律：
- 逆境与冲突才能更好的发展自我
- 生活才是自我发展的主要阵地
-
-
-
要变的内容
-
用好AI：
- 无论如何得先用起来：辅助编码、代码优化、单元测试、冲突咨询、方案建议
- 与AI共赢而非博弈
-
管理理念
- 人性化管理：注重价值感和归属感
- 自组织管理：避免成为团队最大的瓶颈、激发个体的自驱力
-
管理手段
- 授权：成员可能会以为被夺取自主性而丧失自驱力
- 支持：给员工兜底，给他们创造犯错的机会。以目标为牵引
- 共赢：互相成就
- 塑造良好的文化范围
-
管理方法论
-
像解决bug一样去探索管理的方法论
-
团队效能：
-
个体职业素养
-
集体环境效能：
- 工作流程
- 沟通机制
- 文化氛围
- 激励手段
- 目标管理
- 绩效管理
-
工具
-
-
-
